Applications Manager 9.4.

Copyright © 2005-2019 Broadcom. All Rights Reserved. The term 'Broadcom' refers to Broadcom Inc. and/or its subsidiaries.
Contents

Release Information................................................................................................................... 11
Release Notes................................................................................................................... 11
Third-Party Licenses and Notices..................................................................................... 14

Applications Manager Objects................................................................................................... 15

Contacting Technical Support.................................................................................................... 16

Getting Started Guide................................................................................................................ 16

About This Guide.............................................................................................................. 17
Introduction to Applications Manager................................................................................17
How Do I Get Started?............................................................................................ 19
Applications Manager Architecture.......................................................................... 19
Configuring Applications Manager for Your Enterprise............................................ 21
Objects Reduce Development and Maintenance.....................................................23
Overview of Applications Manager Objects............................................................. 24
Moving Around in the Applications Manager Client................................................. 25
Administration.................................................................................................................... 27
Installing the Automation Engine, Agent, and Web Server......................................27
Controlling Access to Applications Manager and its Objects...................................29
Controlling Access to Hosts and Databases........................................................... 31
Managing Output...................................................................................................... 32
Retaining Output Files and Operations Records..................................................... 34
Setting Automation Engine Options......................................................................... 35
Moving Objects from One System to Another......................................................... 36
Development......................................................................................................................38
Creating Jobs to Run Programs and Scripts........................................................... 39
Creating Process Flows to Run a Series of Jobs....................................................41
Adding Dependencies to Jobs................................................................................. 42
Passing Parameters to Programs and Scripts.........................................................44
Adding IF - THEN Logic to Jobs and Process Flows.............................................. 46
Retrieving Values from Databases...........................................................................47
Scheduling Jobs and Process Flows....................................................................... 50
Running a Custom or Third-Party Application......................................................... 53
Getting Notified when a Task Fails.......................................................................... 55
Detecting Failed Tasks by Scanning Output............................................................ 57
Operations......................................................................................................................... 58
Monitoring the System............................................................................................. 59
Finding Out Which Tasks Will Run During Your Shift.............................................. 60
Troubleshooting Failed Tasks...................................................................................62
Handling Task Exceptions........................................................................................ 66
Taking Actions on Tasks.......................................................................................... 66
Viewing/Editing Task Details.................................................................................... 68
Running Tasks Outside the Batch Cycle................................................................. 69
Viewing and Printing Task Output............................................................................71
Controlling Task Priority and Load on the System...................................................73
 Preventing Applications Manager from Launching Tasks........................................ 73
Gantt View Windows................................................................................................ 75

Installation Guide........................................................................................................................76
About This Guide.............................................................................................................. 77
Applications Manager Installation for UNIX and Windows................................................77
Creating the UNIX Account (UNIX Only)................................................................. 78
Assigning Rights and Permissions to the Windows User (Windows Only).............. 79
Creating the Database Account............................................................................... 80
System Information Required for the Installation.....................................................82
Running the Installation Script................................................................................. 84
Starting and Stopping the Applications Manager Processes in UNIX......................85
Starting and Stopping the Applications Manager Processes in Windows................ 86
Opening the Applications Manager Client and Logging In.......................................87
Verifying the Installation........................................................................................... 90
Applications Manager Installation—Advanced Topics.......................................................93
Configuring the Applications Manager Client...........................................................93
Function of the Operating System User.................................................................. 93
Configuring Applications Manager for Oracle RAC................................................. 95
Installing Multiple Automation Engines on One Host...............................................97
Configuration for Machines with Multiple IP Addresses...........................................98
Automation Engine, Agent, and Client Firewall Connections.................................100
Overview of Firewall Settings.................................................................................102
Configuring Agents to Validate Multiple Automation Engine Configurations.......... 102
Using Custom SSL Certificates for Connection Authentication..............................103
Uninstalling Applications Manager......................................................................... 104
Installing a Second RMI Server for Failover.......................................................... 105
Installing a UNIX Remote Agent.....................................................................................107
Defining the UNIX Remote Agent in Applications Manager...................................108
Installing the Remote Agent...................................................................................109
Installing a Windows Remote Agent............................................................................... 110
Defining the Windows Remote Agent in Applications Manager.............................111
Creating the Windows User................................................................................... 113
Running the Installation Program...........................................................................114
Upgrading Applications Manager.................................................................................... 115
Upgrading or updating Tomcat...............................................................................115
Upgrading an Automation Engine and Local Agent...............................................116
Upgrading Remote Agents.....................................................................................118
Verifying the Upgrade.............................................................................................119
Loading Rapid Automation Component .jar Files into Applications Manager................. 120

User Guide............................................................................................................................... 122

About This Guide............................................................................................................ 122
Applications Manager Operations................................................................................... 122
Using the Applications Manager Desktop.............................................................. 124
Working in the Applications Manager Windows.....................................................126
Editing General Desktop and ToolBar Settings......................................................128
Setting Alerts.......................................................................................................... 130
Viewing Operations Reports...................................................................................131
Customizing Tables................................................................................................ 134
Changing Status Colors......................................................................................... 136
 Viewing the About Applications Manager Window.................................................137
Opening the Applications Manager Client and Logging In.....................................138
Requesting and Submitting Jobs and Process Flows.................................................... 141
Requesting Jobs and Process Flows.....................................................................144
Submitting Jobs and Process Flows......................................................................145
Viewing and Printing Output........................................................................................... 148
Working with the Output Window...........................................................................150
Querying the Output Window.................................................................................151
Viewing Output Files with the File Viewer............................................................. 155
Printing, FTPing, and Emailing Output Files..........................................................157
Opening Output Files with Other Applications....................................................... 160
Sharing File Associations with All Applications Manager Users............................ 162
Monitoring and Managing Tasks in Explorer...................................................................163
Using the Explorer Window....................................................................................165
Working with the Backlog.......................................................................................167
Working with History.............................................................................................. 169
Backlog and History Column Descriptions.............................................................170
Focusing the Backlog Display with Explorer..........................................................173
Monitoring with the Status Bar and Object Icons.................................................. 176
Troubleshooting Failed Tasks.................................................................................178
Taking Actions on Tasks in the Backlog................................................................ 180
Viewing and Editing Task Details...........................................................................192
Unsatisfying Tasks as External Predecessors in History....................................... 208
Viewing History in a Gantt Chart........................................................................... 210
How Applications Manager Handles System Failures........................................... 215
Querying and Filtering Explorer...................................................................................... 217
Querying for Tasks in History.................................................................................219
Filtering the Backlog and History........................................................................... 223
Staging Tasks in the Backlog..........................................................................................227
Staging Tasks......................................................................................................... 229
Managing Staged Tasks.........................................................................................231
Working with Agents and Queues.................................................................................. 232
Monitoring Agents...................................................................................................234
Managing Agents....................................................................................................236
Viewing and Printing Automation Engine and Agent Logs.................................... 238
Monitoring Queues................................................................................................. 240
Changing Queue Settings...................................................................................... 242
Administering Queues............................................................................................ 244
Removing External Predecessors by Queue......................................................... 248
Forecasting Jobs and Process Flows............................................................................. 248
Viewing Forecasts.................................................................................................. 250
Viewing Graphical Forecasts..................................................................................252
Setting the FORECAST Job Parameters...............................................................253
Generating Production Schedules......................................................................... 256
Monitoring and Managing Tasks with the Gantt View.....................................................257
Reading the Gantt View Window........................................................................... 259
Interpreting Adjusted Start and End Times............................................................260
Finding Tasks in the Gantt View Window.............................................................. 261
Setting the Gantt View Preferences.......................................................................262
Printing from the Gantt View..................................................................................263
Automation Engine/Agent Status Values........................................................................ 266
Task Status Values..........................................................................................................268
Development Guide..................................................................................................................279
About This Guide............................................................................................................ 279
Applications Manager Development............................................................................... 279
Guidelines for Starting Out in Applications Manager Development....................... 280
Starting Out with Existing Scripts...........................................................................281
Naming Convention Guidelines..............................................................................282
Adding, Editing, and Deleting Applications Manager Objects................................282
Copying Applications Manager Objects................................................................. 284
Viewing Object Reports..........................................................................................286
Viewing Object References.................................................................................... 288
Updating Unsaved Changes.................................................................................. 289
Creating Jobs.................................................................................................................. 290
Defining Jobs..........................................................................................................292
Using the Tabs of the Jobs Window...................................................................... 294
Example: Creating a Job to Run an Existing Script...............................................295
Entering General Information for Jobs...................................................................298
Entering Execution Options for Jobs..................................................................... 304
Specifying Output Options for Jobs....................................................................... 319
Adding Job Documentation.................................................................................... 321
Assigning User Groups to Jobs............................................................................. 324
Troubleshooting Newly Created Jobs.................................................................... 326
Updating Job/Process Flow Characteristics with BULK_CHANGES..................... 329
What Are Process Flow Requestor Jobs?.............................................................331
Creating Process Flows.................................................................................................. 333
Defining Process Flows..........................................................................................335
Using the Tabs of the Process Flows Window...................................................... 336
Entering Execution Options for Process Flows......................................................337
Specifying Output Options for Process Flows....................................................... 339
Introduction to Process Flow Building....................................................................341
Working with Process Flows.................................................................................. 343
Adding Process Flow Components........................................................................350
Arranging Components in a Process Flow............................................................ 355
Creating Component Groups................................................................................. 357
Navigating Large Process Flows........................................................................... 360
Implementing Process Flow Component Change Revisions................................. 361
Viewing a Gantt Chart of the Process Flow...........................................................363
Calculating Process Flow Average Run Times......................................................364
Editing Process Flow Component Information................................................................366
Specifying Calendars and Eligible Run Days........................................................ 368
Setting Execution Options......................................................................................370
How Agent Assignments Are Handled for Process Flow Components..................372
Specifying Output Devices..................................................................................... 374
Specifying Prompt Values...................................................................................... 376
Working with Predecessors.............................................................................................378
Understanding Predecessor Terminology.............................................................. 380
Understanding Predecessor Execution Rules........................................................381
Predecessor Requirement Table............................................................................ 383
Working with Internal Predecessors.......................................................................385
Working with External Predecessors..................................................................... 393
Editing Predecessor Links......................................................................................405
Using the Predecessor Editor Box.........................................................................406
 Changing the AND/OR Logic................................................................................. 408
Saving Preferences for Creating Predecessors.....................................................410
Using Predecessor Links to Accomplish Specialized Tasks.................................. 411
Adding Prompts to Jobs and Process Flows..................................................................418
Deciding which Prompts to Use.............................................................................419
Prompt Formats for Ad Hoc Jobs and Process Flows...........................................421
Adding, Updating, and Deleting Prompts...............................................................426
Setting Minimum and Maximum Values for Prompts............................................. 428
Defining Data Types...............................................................................................428
Copying Prompts from Another Job or Process Flow............................................437
How Multi Select Prompts Work............................................................................ 438
Working with Substitution Variables and Replacement Values....................................... 441
Defining Static Substitution Variables.................................................................... 443
Defining Dynamic Substitution Variables............................................................... 445
Executing Procedures in Dynamic Substitution Variables......................................447
Adding Subvars and Replacement Values to Applications Manager Objects........ 449
Replacement Value Descriptions........................................................................... 450
Creating Local Substitution Variables Using Replacement Values........................ 453
Using Subvars and Replacement Values in Job and Component Prompts........... 454
Passing Values Through a Process Flow with Numeric Subvars.......................... 454
Working with Conditions..................................................................................................465
How Applications Manager Processes Conditions................................................ 467
Adding, Editing, and Deleting Conditions.............................................................. 469
Selecting Condition Values.................................................................................... 472
Copying Conditions from Another Job, Process Flow, or Component................... 484
Using Conditions to Accomplish Common Tasks.................................................. 485
Scheduling Jobs and Process Flows.............................................................................. 504
Adding, Editing, and Deleting Schedules...............................................................506
Entering General Information for Schedules..........................................................508
Entering Schedule Frequencies............................................................................. 510
Creating Workday Schedules.................................................................................513
Creating Fiscal Calendar Schedules......................................................................514
Entering Schedule Exceptions............................................................................... 518
Specifying Prompt Values for Schedules............................................................... 519
Defining Calendars................................................................................................. 520
Displaying Run Dates for Schedules..................................................................... 523
Example Schedules................................................................................................525
Skipping Scheduled Tasks While the Automation Engine Is Stopped....................533
Scheduling for Daylight Saving Time..................................................................... 534
Exporting and Importing Objects.....................................................................................535
Export/Import Flowchart......................................................................................... 537
Export/Import Terms............................................................................................... 540
Building Export Lists...............................................................................................540
Saving Export Lists and Exporting Objects........................................................... 543
Opening Imports and Mapping Objects................................................................. 544
Performing Import Audits....................................................................................... 546
Adding, Editing, and Deleting Map File Entries..................................................... 548
Example: Exporting a Job to Another Applications Manager Instance.................. 550
File Transferring...............................................................................................................553
FTP_JAVA Job....................................................................................................... 554
SFTP_JAVA Job..................................................................................................... 557
FTP Job.................................................................................................................. 558
 Defining Host Logins.............................................................................................. 563
LOADER Job.......................................................................................................... 565
Running Custom Applications from Applications Manager............................................. 567
Understanding Program Type Objects................................................................... 569
Understanding Program Type Scripts.................................................................... 571
Program Execution................................................................................................. 573
Parameter Passing................................................................................................. 577
Output Registration.................................................................................................579
Error Trapping........................................................................................................ 582
DEBUG/Administration and Termination................................................................ 584
Installed Program Types and Program Type Scripts............................................. 585
Run-Time Extensions and Environment Variables..........................................................586
How Run-Time Extensions Work........................................................................... 587
UNIX Run-Time Extension Examples.................................................................... 588
Using Applications Manager System Environment Variables................................ 590
Applications Manager Reserved Words.................................................................592
SURUN - Running UNIX Tasks Under Other Host Logins..............................................595
Three SURUN Program Types.............................................................................. 595
Creating an authoriz.lis File................................................................................... 598
Capturing Output.................................................................................................... 599
SURUN Error Messages and SURUN Debugging................................................ 599
Applications Manager Command Line Utilities............................................................... 600
awrun - The Command Line API for Requesting Tasks.........................................601
awexe - Accessing Applications Manager Capabilities..........................................606
Common awexe Commands You Can Use in Your Scripts................................... 607
AppWorx Command Line Interface - Accessing Explorer Functionality................. 614
Program Type Descriptions.............................................................................................627
AWSQLP.................................................................................................................628
SOCOBOL.............................................................................................................. 631
SHUTDOWN...........................................................................................................636
AWJAVA.................................................................................................................. 638
Sending and Retrieving JMS Messages.........................................................................638
Creating JMS Logins..............................................................................................639
Defining JMS Messages with Conditions...............................................................641
Assigning the JMS Login to the Automation Engine..............................................643
Appendix A: Regular Expression Tables.........................................................................644
Appendix B: awop_api.awrun - Requesting Tasks Through Oracle................................647
Appendix C: Task Action Order...................................................................................... 648

Administration Guide................................................................................................................ 648

About This Guide............................................................................................................ 649
Applications Manager Administration.............................................................................. 649
Configure SMTP Authentication............................................................................. 649
Viewing User Connection Information and Sending Broadcasts............................650
Viewing Server and Agent Connection Information............................................... 652
Viewing Assigned Objects......................................................................................653
Applications Manager Directory Structure..............................................................654
Defining Output Devices................................................................................................. 656
Defining Single Output Devices............................................................................. 657
Defining Distribution Lists.......................................................................................659
Defining Output Groups......................................................................................... 661
Defining Output Interfaces..................................................................................... 663
 Adding Output Options to Output Interface Definitions..........................................666
LP Print Output Interface....................................................................................... 668
Emailing Output...................................................................................................... 673
Faxing Output......................................................................................................... 676
Troubleshooting Output Device Problems............................................................. 678
Applications Manager Security........................................................................................680
Defining Users........................................................................................................ 681
Working with User Groups..................................................................................... 689
Sample User Groups and Users............................................................................698
Defining Database Logins...................................................................................... 701
Working with the Automation Engine and Agents.......................................................... 709
Defining Remote Agents........................................................................................ 711
Specifying Output File Names............................................................................... 714
Setting Automation Engine Options....................................................................... 716
Specifying LDAP Settings...................................................................................... 720
Enabling Applications Manager Auditing............................................................... 723
Specifying Email Settings for the Automation Engine............................................724
Defining Agent Groups...........................................................................................725
Setting the Priorities and Load Factors for Agents in a Regular Agent Group....... 727
Managing System Records.................................................................................... 728
Creating Reports and Browsing the Database............................................................... 730
Steps for Creating Reports.................................................................................... 732
Selecting Tables and Views................................................................................... 733
Adding Report Columns......................................................................................... 736
Editing Report Columns......................................................................................... 738
Example: Creating a Report from Existing SQL.................................................... 741
Example: Adding a Prompt to a Report.................................................................744
Example: Using Prompted NO_SQL Columns...................................................... 749
Example: Finding Components by Alias Name..................................................... 751
Showing Reports and Their SQL from the Reports Window................................. 757
Creating Jobs from Reports................................................................................... 760
Retrieving Historical Data for Applications Manager Historical Analysis Reports...763
Browsing the Applications Manager Database...................................................... 765
Event Logging..................................................................................................................768
Logging Task Events.............................................................................................. 769
Logging Agent Events............................................................................................ 771
Formatting Task and Agent Event Files.................................................................772
Applications Manager Processes.................................................................................... 774
Starting and Stopping Automation Engine and Agent Processes.......................... 775
The watchworx Process......................................................................................... 778
The awcomm Process............................................................................................782
The AgentService Process.....................................................................................783
The RmiServer Process......................................................................................... 783
Task and Program Execution................................................................................. 785
The awexe Process................................................................................................786
How a Task Runs............................................................................................................787
Request to the Automation Engine........................................................................ 788
pm File....................................................................................................................789
BODY......................................................................................................................790
Program Type (before program execution)............................................................ 791
Program.................................................................................................................. 792
Program Type (after program execution)............................................................... 793
 BODY (after return from Program Type script)...................................................... 793
Automation Engine................................................................................................. 793
Troubleshooting with Log Files and Debug.................................................................... 794
Applications Manager Standard Out Log Files and Program Debug..................... 794
Background Process Logs..................................................................................... 796
Setting Client, Server, Oracle Trace, and All Agent Debug................................... 797
Setting startso Debug in UNIX...............................................................................804
Debugging the awcomm and awnetex C Processes............................................. 804
Copying and Moving Applications Manager Instances................................................... 805
Before You Begin................................................................................................... 806
Three-tiered Methodology...................................................................................... 807
Stopping and Starting Applications Manager Processes....................................... 809
Copying or Moving an Automation Engine/Database to a New Machine...............810
Copying or Moving an Automation Engine/Database to an Existing Machine........811
Copying or Moving an Automation Engine to a New Machine...............................813
Copying or Moving an Applications Manager Database........................................815
Host and Client Customization........................................................................................818
Background Manager and WatchWorx Variables.................................................. 818
awenv.ini Environment Initialization File.................................................................819
Options.properties File........................................................................................... 825
Masters.properties File........................................................................................... 828
Setting Up SSH Shared Keys................................................................................829
Preinstalled Job and Process Flow Descriptions............................................................831
Customizable Columns....................................................................................................833

Oracle Applications Extension Guide.......................................................................................846

About This Guide............................................................................................................ 847
Introduction to the Applications Manager Oracle Applications Extension....................... 847
What's New in the Applications Manager Oracle Applications Extension.............. 848
Installing and Upgrading the OAE Extension................................................................. 849
Setting Up Oracle Advanced Queuing...................................................................849
Setting Up an OAE Oracle User Account..............................................................851
Creating OAE Login Objects..................................................................................852
Defining the OAE Agent.........................................................................................854
Importing the Oracle Applications Extension Objects............................................ 855
Upgrading the OAE Extension............................................................................... 857
Using OAE Auxiliary Agent Functions............................................................................ 859
Querying Oracle E-Business Suite Programs........................................................861
Creating OAE Jobs................................................................................................ 863
Creating OAE Process Flows................................................................................ 864
Intercepting OAE Jobs........................................................................................... 866
Working with Oracle Applications Extension...................................................................867
Description of the Generic CONCSUB Job........................................................... 868
Managing OEBS programs through Applications Manager................................... 870
Monitoring OAE Jobs............................................................................................. 871
Storing Values for Variables with OUTPUT_FILE.................................................. 874
Values Available for the OUTPUT_FILE Environment Variable............................. 876
Implications of Changing Database Account Passwords.......................................878
Applications Manager Environment Variables for OAE...................................................878
Additions Made to the Oracle E-Business Suite Database............................................ 879
PeopleSoft Extension Guide.................................................................................................... 879
About This Guide............................................................................................................ 880
Introduction to the Applications Manager PeopleSoft Extension.................................... 880
What's New in the Applications Manager PeopleSoft Extension........................... 881
Installing the Applications Manager PeopleSoft Extension.............................................881
Defining the PeopleSoft Login and User............................................................... 882
Installing the PeopleSoft Agent in Applications Manager...................................... 883
Specifying PeopleSoft Parameters for a PeopleSoft Agent................................... 886
Importing the PeopleSoft Objects.......................................................................... 887
Importing the Component Interface for PeopleTools 8.43 - 8.48............................888
Importing the Component Interface for PeopleTools 8.22......................................889
Defining Permissions for the Applications Manager PeopleSoft User................... 891
Using the Inline Bind Variables.............................................................................. 893
Running Jobs as Other Users............................................................................... 898
Upgrading the PeopleSoft Extension..................................................................... 902
Defining PeopleSoft Jobs................................................................................................902
Querying PeopleSoft Programs............................................................................. 904
Creating PeopleSoft Jobs...................................................................................... 905
Editing PeopleSoft Jobs......................................................................................... 906
Using Applications Manager PSE Variables in Output Paths................................ 908
Creating Subvars and Data Types.........................................................................909
Defining PeopleSoft Reports..................................................................................911
Running and Monitoring PeopleSoft Tasks and Processes............................................ 913
Requesting PeopleSoft Jobs..................................................................................914
Scheduling PeopleSoft Jobs and Process Flows.................................................. 916
Monitoring PeopleSoft Jobs................................................................................... 917
Reviewing PeopleSoft Job Details......................................................................... 920
Taking Actions on PeopleSoft Jobs....................................................................... 922
Troubleshooting the Applications Manager PeopleSoft Extension..................................924
Agent Goes to Error...............................................................................................924
PSProperties not loaded from file.......................................................................... 925
5007 : Component Interface APWRX_SELECT must be installed........................ 925
Job Aborts.............................................................................................................. 926
(0,0) : DOWNbea.jolt.ServiceException: Invalid Session....................................... 927
(90,6) : Not Authorized (90,6)................................................................................ 927
8. (65,8) : You are not authorized to run................................................................927
Caused by: 5504 : (2,116) : Invalid parameter 1 for function CreateRowset..........928
AwE-9999 Internal Error - index out of range........................................................ 928
<User name> is an Invalid User typed the wrong password................................. 928
A Job Errors in PeopleSoft, but Completes Successfully in Applications
Manager..............................................................................................................929
Troubleshooting Difficult PeopleSoft Job and Process Launch Errors................... 929

Disaster Recovery.................................................................................................................... 933

Usage Data (Telemetry)........................................................................................................... 934

Documentation Legal Notice.................................................................................................... 935

 Applications Manager 9.4.1

1 Release Information
Release highlights for Applications Manager 9.x

Warning: Broadcom highly recommends that you back up your Oracle data and Applications Manager file
system before upgrading due to table changes in this release. There is no rollback procedure for Oracle
data and the upgrade process does not back up your data or file system.
New Features Only in Major and Minor Versions of All Automic Software
Aways install the latest Service Pack or Hotfix. Both contain valuable corrections and bug fixes between Major and
Minor Releases, where new features and enhancements are introduced.
The software version information consists of the following identifiers, as shown in this example:
12.2.1 HF 1
• Major Release: 12
This is the main version of a software release. It is identified by the first segment of the entire version number.
• Minor Release: 2
This includes new features, modifications, and corrections that may contain major changes such as database
modifications. It is identified by the second segment of the entire version number.
Major and Minor releases for Automation Engine are feature releases supplied at 9-month intervals.
• Service Pack: 1
This is a patch for a release and contains corrections for errors. New features or modifications are not included.
Service packs are identified by the third segment of the entire version number.
• Hotfix: HF1
This is a minor sub-release to remove malfunctions and defects. Hotfixes are indicated by an HF number after
the version number.
Service Packs and Hotfixes are maintenance releases supplied at 4-month intervals.
Getting the Latest Information
Documentation, release notes, and other information is often updated after software is released. The table below
shows where to find the most recent information for Automic software releases.

To find the most recent: Go to the:

Bug fixes, known issues, and workarounds Automic Download Center

Product documentation • Applications Manager Documentation

• The Banner Rapid Automation Agent for Local
Clients Documentation
• The Banner Rapid Automation Agent for the Automic
Web Interface Documentation
• All other Automic Hosted Documentation
• Broadcom Technical Documentation

Compatibility for Automic software components, Automic Compatibility Checker

versions, and sub-components
Broadcom product support Broadcom Support

Upgrading an Existing Automation Engine

Warning: It is necessary that you back up your database and export the Applications Manager instance
before upgrading.

Release Notes
Applications Manager V9.4.1
 Applications Manager 9.4.1

What's New?
Applications Manager 9.4.1 addresses major vulnerabilities reported with Log4j libraries. It also includes several
bug fixes.
Applications Manager V9.4.0
What's New?
• Applications Manager 9.4.0 comes with improved disaster recovery management. For more information, refer to
Disaster Recovery.
• Apache Tomcat is now the default HTTP server. For more information refer to Upgrading or updating Tomcat.
• Starting from Applications Manager 9.4.0, Perl is no longer being shipped with the product image for UNIX-
based operating systems.
• New fields are introduced for Banner Output.
• Three new grants are added for the Banner database SYS user. For more information refer to, Issuing Grants to
Create the BANWORX Banner User.
• The product help will now be available online only.
Applications Manager V9.3.5
What's New?
• SMTP Authentication: You can now configure SMTP authentication for the master agent. For more information,
refer to Configure SMTP Authentication.
• Custom SSL certificates for Connection Authentication: Improvements have been made for use SSL certificates.
For more information, refer to Using Custom SSL Certificates for Connection Authentication.
• Notifications: You can now attach a PDF to the notification in the portrait or landscape format with size limit
option. For more information, refer to Defining Notifications.
Applications Manager V9.3.4
What's New?
• Broadcom may request you for the telemetry report as and when required. For more information, refer to
Applications Manager Telemetry data.
• You can now add a component with a right-click to an existing job or process flow and also retain the
component's configuration. For more information, refer to Add components and retain the existing configuration.
• You can now have different colors for Applications Manager main window for different deployments of
Applications Manager. For example, you may want to have a Brown color for the development environment and
Green color for the production environment. For more information, refer to Configure Applications Manager Main
Window Color.
• Applications Manager 9.3.4 now supports RedHat Enterprise Linux 8.
Applications Manager v9.3
What's New
Oracle 18c Now Supported
In Applications Manager 9.3, Oracle 18c databases are supported. For special instructions, see Creating the
Database Account in the Installation Guide.
Specifying a Unique Location for Multiple Keystore Files in v9.3.1
Starting with v9.3.1, you can specify a unique location for multiple keystore files. To do this, you create a C:\Users
\<user name>\AppWorx\<master name> folder for each master in the connections.properties file on each
user's client machine where <user name> is the actual user's name and <master name> is the name of the
master. Then put copies of the user_keystore and user_keystore_config files for each master the sub-directory
for that master.
RunClient.jar Error Messages Now in the startClient.log file in v9.3.1
When starting the local client by double clicking on RunClient.jar (or a shortcut to it) in version 9.3.1 or above, if it
fails to start the error will now be in the startClient.log file.
Changes in Behavior
Executable .jar File for the Client Must Be Downloaded and Configured
You must now download the Applications Manager client from the URL set during installation. To get this URL,
see your Applications Manager administrator. Before logging in the first time, you need to configure the client for
 Applications Manager 9.4.1

the Automation Engine(s) you will be logging into. Once configured, you open an executable .jar file. For more
information, see Opening the Applications Manager Client and Logging In in the User Guide.
Custom SSL Certificates for Connection Authentication Now Required
You must use a custom SSL certificate for connection authentication by creating user_keystore and
user_keystore_config files on the Automation Engine and client machines. For more information, see Using
Custom SSL Certificates for Connection Authentication in the Installation Guide.
Keyfiles No Longer Required
Starting with Applications Manager 9.3, license checking with keyfiles is no longer required for Automation Engines
or agents.

Applications Manager v9.2

What's New
Requesting a Job or Process Flow from its Definition
You can now request a Job or Process Flow from it's definition. This opens the Submit window, like the Request
window does. This is beneficial for testing changes you make to the object.
Using Retention Days for Notification Log Files
When you define a Job, you can set the number of days the output will be retained by Applications Manager in the
Retention days setting on each Job's Output tab. When a Notification is assigned to the Job, it will use that Job's
retention days to determine when to delete the Notification's log files.The SODELETE Job (alias DELDEFAULT)
deletes the output files that have exceeded their retention settings.
Changing Database Login Passwords without Restarting
You can now change Database Login passwords used for Subvars and conditions without restarting.Ignoring Max
Length Prompt Validation within Process Flow Component Prompt Overrides when { } Are UsedAny component
prompt value beginning with { ignores field limitations in order to allow Subvar overrides.This functions the same
regardless of whether Upper Case is checked at any level.
Using Oracle Advanced Queuing for OAE
Removed DBMS_PIPE from OAE-related code and replaced the functionality with Oracle Advanced Queuing (AQ).
This change requires a dedicated AQ admin account to manage the AQ tables and Queues.
All OAE related database schema objects can now be created in a dedicated OAE Oracle User, instead of using
APPS User. The existing OAE User can continue to use APPS account to deploy OAE objects or migrate the OAE
setup to the dedicated Oracle User through some easy steps.
Running an RA Oracle EBS Agent and Applications Manager OAE Agent in same EBS database
You can now running an RA Oracle EBS Agent and Applications Manager OAE Agent in same EBS database. This
is beneficial when you are moving from the Applications Manager with the OAE Agent to Applications Manager or
Automation Engine with the OEBS Agent.
Applications Manager v9.1
What's New
Auto-logout Client Setting in Options.properties
You can now set the number of minutes of inactivity before an auto-logout of the Java client by adding
IdleLogoffTime=<number of minutes> to the Options.properties file. To unset this options, set
IdleLogoffTime=0.
Support for Stronger Strength Ephemeral DH keys in the SunJSSE Provider
We set jdk.tls.ephemeralDHKeySize to Java version-specific values: 2048 for Java 1.8 and above. If you want
to use 2048 bit certificate keys, both the server (rmiserver) and the client (UI or AgentService) need to be running
Java 1.8 or above. For more information, see your Java documentation.
Applications Manager v9.0
What's New
Active-Passive Failover
The Applications Manager Automation Engine now supports active-passive failover. A secondary Applications
Manager RMI server can be setup and run in stand-by mode (active-passive), so that in the event that the primary
Applications Manager Automation Engine goes down, the stand-by RMI server will become the active Automation
Engine. When the stand-by RMI server becomes active, the Agents will reconnect to it automatically; with the
exception of the Local Agent. That is because the Local Agent is part of the Automation Engine installation, and
 Applications Manager 9.4.1

integrated with the specific Automation Engine system. Therefore, in systems that require RMI server failover, it is
recommended that all Jobs be setup to run on Remote Agents.
Platform and Oracle Support
Version 9 is the first Applications Manager release that supports Oracle 12c databases. When using Oracle 12c
database and you have an Oracle Enterprise Edition multi-tenant system or Oracle Standard Edition single tenant
system, you must install Applications Manager into a pluggable database (PDB) within a container. Your DBA is
responsible for creating the pluggable database.
Enabling/Disabling RMI Server Debug with the RMI_DEBUG Job
You can now enable or disable RMI server debug by running the RMI_DEBUG Job. Like all Applications Manager
Jobs, you can request and submit RMI_DEBUG to run it ad hoc, or schedule it. Activate or deactivate RMI server
debug by setting the Enable prompt to Yes or No. The RMI_DEBUG Job is included in the RMI_DEBUG import file.
Desupported Features
The following features are desupported for Applications Manager v9:
• The Dashboard
• AppMaster
• Remote Method Extension Agents
• VMS Agents
• OS400 Agents
• ZOS (mainframe bridge) Agents
The supported platforms for the Automation Engine and its Agents change between releases. For a list of
supported platforms for the Automation Engine and Agents in this release, see the Matrix below.
Known Issue: You Cannot Retrieve a Local WSDL File for a SOAP Login Object
You cannot retrieve a local WSDL file for a SOAP Login object using the Web Service Agent. This will be fixed in
Applications Manager v9.0 Service Pack 1 and a patch is available from Broadcom Support.

Third-Party Licenses and Notices

Third Party Licensees and Notices
The Apache Software License, Version 1.1
Copyright (c) 1999 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment:
"This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowledgement may appear in the software itself, if and wherever such third-party
acknowledgements normally appear.
4. The names "The Jakarta Project", "Jakarta-Regexp", and "Apache Software Foundation" must not be used to
endorse or promote products derived from this software without prior written permission. For written permission,
please contact [email protected].
5. Products derived from this software may not be called "Apache" nor may "Apache" appear in their names without
prior written permission of the Apache Group.
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION
OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 Applications Manager 9.4.1

GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER

CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
============================================================
This software consists of voluntary contributions made by many individuals on behalf of the Apache Software
Foundation.
Code Licensed from RSA Data Security
This product includes code licensed from RSA Data Security.

2 Applications Manager Objects

Objects are presented in the order they are listed in the sub-menus under Object Admin on the
Applications Manager Desktop.
The objects are presented below in the same order they are listed in the sub-menus under Object Admin on the
Applications Manager Desktop. Their organization is based on the users who are most likely to create each object
type.
Administration
• Agent Groups: balance the load between Agents on one or more machines. For more information, see Defining
Agent Groups.
• Agents: are instances of Applications Manager. An Agent is installed on each machine where tasks are
executed. An Agent can be an Automation Engine's Local Agent, a Remote Agent, or an application-specific
Agent such as Oracle Applications or PeopleSoft. For more information, see Defining Remote Agents.
• Logins: allow operators and programmers to run programs that access a database or host without having to
know the login and password. For more information, see Defining Database Logins and Defining Host Logins.
• Output Devices: define any Output Device including printers, faxes, and email. You can print to a single Output
Device, or, through the use of distribution lists, multiple Output Devices. For more information, see Defining
Output Devices.
• Output Groups: define organizational classes of Output Devices. When you define Applications Manager
Output Devices, you assign them to one or more Output Groups. For more information, see Defining Output
Groups.
• Output Interfaces: interface between Applications Manager and an Output Device. For more information, see
Defining Output Interfaces.
• User Authorities: control User access to Applications Manager windows and can give Users add privileges
for objects. You assign User Authorities to your User Groups. For more information, see Understanding User
Authorities.
• User Groups: control access to all areas of Applications Manager. In a traditional system, you create groups of
Users, Output Devices, and Applications. User Groups can contain any combination of objects, and objects can
be assigned to any number of User Groups. For more information, see Defining User Groups.
• User Options: are the same options assigned to Users, but as objects, they are assigned to a User Group.
When User Options are assigned to a User Group, all Users in that User Group will have that User Option set to
true for them. You cannot add, edit, or delete User Option objects like other Applications Manager objects. You
can only assign them to User Groups. For more information, see Setting User Options.
• Users: control access to Applications Manager. You can assign names, access permissions, User Options, and
User Groups to Users. For more information, see Defining Users.
Development
• Applications: logically group Jobs and Process Flows. Used to filter lists of Jobs and Process Flows. For more
information, see Defining Applications.
• Calendars: define groups of days, such as holidays, that you can use for schedules. Schedules can run on, or
skip, the days in a Calendar. For more information, see Defining Calendars.
• Data Types: specify the format for data passed to programs. They can include SQL statements that validate
responses and allow you to pick from lists. For more information, see Defining Data Types.
• Environment Variables: store values you define for one or more variables as a single Applications Manager
object. For more information, see Defining Environment Variables.
 Applications Manager 9.4.1

• Jobs: are the basic building blocks in Applications Manager. For each program you want to run (such as FTP,
application, or database load), you must create a Job. A Job contains all the information required to execute
a program and handle its output. Jobs are run both individually and as components of Applications Manager
Process Flows. Furthermore, a Job can be a component of as many Process Flows as you wish. If you change
a Job definition, the change is applied to every Process Flow that includes it. For more information, see Defining
Jobs.
• Libraries: define the path for the program that a Job runs. For more information, see Defining Libraries.
• Message Templates: specify text to include in Notification output files. They allow the use of Substitution
Variables and Replacement Values for variable text. For more information, see Defining Message Templates.
• Notifications: send dynamic messages that are based upon on a task's status through email or any other
defined Output Device. For more information, see Defining Notifications.
• Output Scans: scan output for text strings that indicate if a task has failed or succeeded. For more information,
see Defining Output Scans.
• Process Flows: are containers that include one or more components (Jobs and other Process Flows), general
scheduling information for the Process Flow, specific eligibility for each of its components, and conditions that
must be met for each component to run. For more information, see Defining Process Flows.
• Program Types: define how programs accept input and handle output. For more information, see Defining
Program Types.
• Reports: view Reports for data in the Applications Manager database. Developers and administrators can
create custom SQL Reports in the Applications Manager client. For more information, see Steps for Creating
Reports.
• Substitution Variables: store values that can be used in Jobs and Process Flows. Applications Manager lets
you use Substitution Variables, such as #today, in prompts and execution conditions assigned to Jobs. For more
information, see Defining Static Substitution Variables and Defining Dynamic Substitution Variables.
Operations
• Queues: control the flow of tasks. All tasks must pass through an Applications Manager Queue to be executed.
For more information, see Defining Queues.
• Thread Schedules: are assigned to one or more Queues or Agents. Thread Schedules define the number of
concurrent tasks that can run through a Queue or Agent at different times of the day. For more information, see
Defining Thread Schedules.

3 Contacting Technical Support

We have the support team you can trust. Our team of professionals is ready to support you, anytime and anywhere.
Three support centers located in Europe, the United States, and Asia Pacific build the core of the organization.
They make sure that your closest Automic experts are never more than a few hours flight away, no matter on which
continent your subsidiaries and data centers are located. The Automic Automation Platform is designed to provide
global connectivity for international companies. You are employing the Automic Automation Platform on a global
scale and therefore you can expect global services.
Our customer's portal, the Broadcom Supportsite is the place where you will find everything you need to know
about Automic in order to make sure you are using our products to their fullest potential. It's all right here in one
place: from service hotfixes, release notes, and the Automic Automation Platform manuals to our trouble-ticket
system that lets you check the status of your support cases directly from our website. You will also find white
papers with information about the latest Automic developments, as well as the Automic Roadmap, which provides
sneak previews of future development projects, information about exclusive customer events, and much more.

4 Getting Started Guide

The Applications Manager Getting Started Guide provides an overview of how operators,
developers, and administrators use Applications Manager. By reading the appropriate topics in
these chapters, you will learn how the various Applications Manager features relate to your job.
The Applications Manager Getting Started Guide provides an overview of how operators, developers, and
administrators use Applications Manager. By reading the appropriate topics in these chapters, you will learn how
the various Applications Manager features relate to your job.
Welcome to Applications Manager. The Getting Started Guide is intended to help you learn your way around
Applications Manager. It is part of the complete Applications Manager documentation set which includes:
 Applications Manager 9.4.1

• Getting Started Guide

• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

About This Guide

The Applications Manager Getting Started Guide provides an overview of how operators, developers, and
administrators use Applications Manager. By reading the appropriate topics in these chapters, you will learn how
the various Applications Manager features relate to your job.
Welcome to Applications Manager. The Getting Started Guide is intended to help you learn your way around
Applications Manager. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Introduction to Applications Manager

Congratulations! You have just purchased the most powerful and flexible process automation and task scheduling
tool for distributed environments. You can use Applications Manager software to automate enterprise scheduling,
integrate applications, and accelerate business processes. If you fully implement Applications Manager, you can
reduce IT operating expenses, speed the development process, and improve business processes. The benefits are
summarized in the image below.
 Applications Manager 9.4.1

Reduce Operating Expenses

Applications Manager includes features that enable you to approach full automation of operations. These features
include predecessors, conditions, and Substitution Variables. Underlying these features is the ability of Applications
Manager to make scheduling decisions based on queries of your corporate databases. Applications Manager is,
in the true sense of the word, a "smart" scheduler. Full automation allows you to allocate operations resources to
other critical tasks, reducing your operations expenses.
Speed Development
In a traditional development environment, scripts drive operations. Scripts incorporate the information required to
run one or more programs on a set schedule, direct output, and handle exceptions. The problem with scripts is the
time required to write and maintain them. For example, if an Output Device definition changes, you must change it
in every script.
Applications Manager takes the individual components of a script such as programs, schedules, Output Devices,
and variables, and lets you define them as discrete objects. You can then combine the objects in an unlimited
number of combinations to handle your operations. There are two distinct advantages:
• You can change an object in one place, and have the changes roll over to every use of the object.
• You can quickly put objects together to build a Process Flow.
Improve Business Processes
There is a good possibility that many of the procedures you have in place today are based on the capabilities of
older or legacy systems. Operations ran using scripts, heavily dependent on operator intervention. Developers
wrote programs based on manual input from operators and users. With Applications Manager, many of these
processes can be streamlined and automated.
Getting the Most Out of Applications Manager
For your company to get the largest return on its investment in Applications Manager, development, production,
and operations must work together. As a group, you need to examine each of your current processes and how
you can use Applications Manager to improve those processes. The result should be that development spends
less time writing programs, production uses smart scheduling to reduce total execution time and balance load on
servers, and operations focuses on monitoring and troubleshooting, rather than running tasks.
 Applications Manager 9.4.1

How Do I Get Started?

How you get started with Applications Manager depends on whether you are an Applications
Manager administrator, developer, or operator.
With the power and flexibility of Applications Manager comes complexity. You will need to invest some time
learning the product to reap the rewards. So, how do you get started? That depends on your role. Are you primarily
an Applications Manager administrator, developer, or operator? Below we present Getting Started road maps for
each major type of user.
Applications Manager Administrator Road Map
If you are the Applications Manager administrator, consider proceeding as follows:
• Finish reading this guide.
• Install the development instance of Applications Manager if it's not already installed. See the Installation
Guide for detailed installation instructions.
• Read through the Administration Guide.
• Determine the initial set of User Groups that you will create to control access to the functions in Applications
Manager.
• Set up User objects for the initial group of people that will be using Applications Manager. The key Users in the
beginning will be the developers.
Developer Road Map
If you are a developer, consider proceeding as follows:
• Finish reading this guide.
• Get your user name and password from your Applications Manager administrator so that you can log into
the Applications Manager client.
• Read through the Development Guide.
• Select one relatively simple series of processes that you want to automate in Applications Manager.
• Create Jobs for each program.
• Create a Process Flow and add the Jobs to the Process Flow. If you have been running programs with scripts,
the Process Flow should replace the scripts.
Operator Road Map
If you are an operator, consider proceeding as follows:
• Finish reading this guide.
• Get your user name and password from your Applications Manager administrator so that you can log into
the Applications Manager client.
• Read through the User Guide.
• Experiment with the Explorer window, running some of the pre-loaded Jobs that ship with Applications
Manager.
Reading This Guide
We included this as the first step in the road maps above, but we wanted to repeat the suggestion here. Continue
reading this Getting Started Guide. Regardless of your role with Applications Manager, we recommend reading the
entire Getting Started Guide. It will give you a good overview of all the tasks that should be performed to get the
maximum benefit from Applications Manager. While you may not perform all the tasks, it will be useful for you to
know what others are doing with the product.
Getting Training
Broadcom Education offers basic training courses that orient you to the product and show you how to use the
major features. These resources provide a fast and easy way to get started with Applications Manager. For more
information, see Broadcom Education.

Applications Manager Architecture

The Applications Manager architecture has been designed to create a robust, scalable system. At a minimum, an
Applications Manager installation includes the following components:
• Applications Manager Automation Engine and Local Agent
• Applications Manager Oracle database
• RMI server
 Applications Manager 9.4.1

• A Web server to "serve" the Java client to a PC or other workstation

• Clients
In larger systems, you may also have one or more Remote Agents. The diagram below shows the basic
components.

Automation Engine
The Automation Engine is the execution logic or brain of Applications Manager. It monitors Job and Process Flow
schedules and, at the appropriate time, sends them to the designated local or Remote Agent for execution. The
Automation Engine communicates with the Applications Manager database, where all object definitions are stored.
Local Agent
At a minimum, a basic Applications Manager setup will include a single Automation Engine and its Local Agent.
The Local Agent runs programs or executes scripts on the host machine where the Applications Manager
Automation Engine is installed. It receives commands from the Automation Engine.
Applications Manager Database
Applications Manager uses object definitions stored in an Oracle database to give it an advantage over all other
schedulers. When you create a Job, Process Flow, or other Applications Manager object, the definition is stored
in the Applications Manager Oracle relational database. You can then use the objects to build more complex
objects. For example, you might define a Database Login, then assign that login to many different Jobs. If the
login changes, you change it in one place, and Applications Manager uses the new definition everywhere it is
referenced. This object-oriented approach makes it easy to update and maintain the Applications Manager system.
Client
You access Applications Manager through a Java client. The client machine is the PC used to access the
Applications Manager graphical user interface. This means you can access Applications Manager from a PC or
workstation that has a Web browser. Client software provides access to all Applications Manager functions and
features. The clients communicate directly with the Applications Manager Automation Engine. You can have any
number of clients.
Remote Agent
 Applications Manager 9.4.1

In larger systems, you may have one or more Applications Manager Remote Agents on other servers. A Remote
Agent must be installed on each machine where tasks are executed. Any number of Remote Agents can report to a
single Automation Engine. Remote Agents may run on UNIX and Windows platforms.
The Automation Engine will schedule and control task execution on all the Agents assigned to it. The Agent
monitors tasks until they complete.

Configuring Applications Manager for Your Enterprise

The size of your enterprise computing environment will dictate the Applications Manager configuration. To get you
started, we will describe the typical configurations for small, medium, and large environments.
Small System
Even if you are installing Applications Manager on a small system, you will need the following components:
• Applications Manager Automation Engine and Local Agent
• Applications Manager Oracle database
• Clients
This configuration is shown below.

Medium System
If you are installing Applications Manager in a medium sized system, you will most likely add several Applications
Manager Remote Agents to execute programs on other machines. This configuration is shown below.
 Applications Manager 9.4.1

Large System
In a large system, you may choose to install two or more Applications Manager Automation Engines. This
configuration is shown below.
 Applications Manager 9.4.1

An Applications Manager Automation Engine can process hundreds of thousands of tasks a day, so the choice
to install more than one Automation Engine is usually not because of load. A more likely reason is that you
are running Applications Manager in different data processing centers and do not want to depend on network
connections between the Automation Engine and Remote Agents.

Objects Reduce Development and Maintenance

Applications Manager replaces scripts with an object-oriented approach to process automation. In a traditional
operations environment, scripts drive process automation. Scripts incorporate the information required to run one
or more programs, direct output, and handle exceptions. The problem with scripts is the time required to write and
maintain them.
Applications Manager takes the individual components of a script such as program interfaces, Database Logins,
Queues, and Output Devices, and lets you define them as discrete objects. You can then combine the objects in
an unlimited number of combinations to handle your process automation and operations. And you can do all of this
without detailed knowledge of the operating systems. Another advantage is that when an object is changed, those
changes roll over to every use of the object.
The diagram below shows several Program Types, Logins, Queues, and Output Devices defined. These are
combined to create Jobs. The Jobs are then combined to create Process Flows. For example, Job A in the figure
uses the following objects:
• Program Type: ORACLE
• Login: ORC_FIN
• Queue: BATCH
• Output Device: PAYROLL
The program specified for Job A is "GL Import." This is the name of the program that will be run by this Job, and is
not an object in Applications Manager.
The "End-of-Period Close" Process Flow is made up of Jobs A through F. Notice that Jobs D and E can run
concurrently, while Jobs A, B, C, and F run sequentially.
All of the objects defined in the illustration, including the Jobs and Process Flow, can be reused in Applications
Manager.
 Applications Manager 9.4.1

Reports
To help you review the objects that have been created, Applications Manager includes many object Reports. The
Reports list all objects of each type, and in some cases, additional information about the objects.

Overview of Applications Manager Objects

The previous topic describes some of the objects you use to build Jobs. This topic describes all of the objects
available in Applications Manager. The objects are presented below in the same order they are listed in the sub-
menus under Object Admin on the Applications Manager Desktop. Their organization is based on the users who
are most likely to create each object.
Administration
• Agent Groups: balance the load between Agents on one or more machines.
 Applications Manager 9.4.1

• Agents: are instances of Applications Manager. An Agent is installed on each machine where tasks are
executed. An Agent can be an Automation Engine's Local Agent, a Remote Agent, or an application-specific
Agent such as Oracle Applications or PeopleSoft.
• Logins: allow operators and programmers to run programs that access a database or host without having to
know the login and password.
• Output Devices: define any Output Device including printers, faxes, and email. You can print to a single Output
Device, or, through the use of distribution lists, multiple Output Devices.
• Output Groups: define organizational classes of Output Devices. When you define Applications Manager
Output Devices, you assign them to one or more Output Groups.
• Output Interfaces: interface between Applications Manager and an Output Device.
• User Authorities: control User access to Applications Manager windows and can give Users add privileges for
objects. You assign User Authorities to your User Groups.
• User Groups: control access to all areas of Applications Manager. In a traditional system, you create groups of
Users, Output Devices, and Applications. User Groups can contain any combination of objects, and objects can
be assigned to any number of User Groups.
• User Options: are the same options assigned to Users, but as objects, they are assigned to a User Group.
When User Options are assigned to a User Group, all Users in that User Group will have that User Option set to
true for them. You cannot add, edit, or delete User Option objects like other Applications Manager objects. You
can only assign them to User Groups.
• Users: control access to Applications Manager. You can assign names, access permissions, User Options, and
User Groups to Users.
Development
• Applications: logically group Jobs and Process Flows. Used to filter lists of Jobs and Process Flows.
• Calendars: define groups of days, such as holidays, that you can use for schedules. Schedules can run on, or
skip, the days in a Calendar.
• Data Types: specify the format for data passed to programs. They can include SQL statements that validate
responses and allow you to pick from lists.
• Environment Variables: store values you define for one or more variables as a single Applications Manager
object.
• Jobs: are the basic building blocks in Applications Manager. For each program you want to run (such as FTP,
application, or database load), you must create a Job. A Job contains all the information required to execute
a program and handle its output. Jobs are run both individually and as components of Applications Manager
Process Flows. Furthermore, a Job can be a component of as many Process Flows as you wish. If you change
a Job definition, the change is applied to every Process Flow that includes it.
• Libraries: define the path for the program that a Job runs.
• Message Templates: specify text to include in Notification output files. They allow the use of Substitution
Variables and Replacement Values for variable text.
• Notifications: send dynamic messages that are based upon on a task's status through email or any other
defined Output Device.
• Output Scans: scan output for text strings that indicate if a task has failed or succeeded.
• Process Flows: are containers that include one or more components (Jobs and other Process Flows), general
scheduling information for the Process Flow, specific eligibility for each of its components, and conditions that
must be met for each component to run.
• Program Types: define how programs accept input and handle output.
• Reports: view Reports for data in the Applications Manager database. Developers and administrators can
create custom SQL Reports in the Applications Manager client.
• Substitution Variables: store values that can be used in Jobs and Process Flows. Applications Manager lets
you use Substitution Variables, such as #today, in prompts and execution conditions assigned to Jobs.
Operations
• Queues: control the flow of tasks. All tasks must pass through an Applications Manager Queue to be executed.
• Thread Schedules: are assigned to one or more Queues or Agents. Thread Schedules define the number of
concurrent tasks that can run through a Queue or Agent at different times of the day.

Moving Around in the Applications Manager Client

The Applications Manager desktop includes a work space for windows and taskbar buttons similar to the desktop
used by many Windows applications. You can access all Applications Manager features and options using icons
and menu items on the desktop.
 Applications Manager 9.4.1

When you log in to Applications Manager, you are taken to the desktop shown below. From the desktop, you can
access all Applications Manager features and functions.

Opening Windows with the Toolbar

The toolbar at the top of the window displays a row of object icons. When you mouse over an icon, a ToolTip
displays the name of the icon. Clicking an icon opens the corresponding window. You can also access the windows
from the Operations and Object Admin menus. Users can choose which icons they want displayed in the toolbar.
Listings under the Activities menu open windows such as Explorer where you monitor the system, and Requests
where you run ad hoc tasks.
Listings under the Object Admin menu open selector windows where you can view, add, edit, or delete definitions
of objects such as Jobs, Process Flows, and Output Devices.
Selecting Active Windows with the Taskbar
When you open a window, an icon is placed in the taskbar running across the bottom of the desktop. The taskbar
gives you quick access to any open window, making it easy for you to switch back and forth while editing objects.
Using Selector Windows to Add, Edit, and Delete Objects
 Applications Manager 9.4.1

Selector windows are used to manage Applications Manager objects. They are displayed when you select an icon
from the toolbar or an item from the Object Admin menu. There is a selector window for each type of Applications
Manager object. From a selector window, you can add, edit, and delete objects. In the image below, the New button
is selected on the Queues Selector window and a new Queue is being defined.

Jumping to Selector Windows from Fields

In many object definitions, you will see icons at the end of the data entry fields. For example, in the image above,
there is a schedule icon at the end of the Thread Schedule field. Clicking on this icon will open the Thread
Schedules Selector window where you can create a new Thread Schedule or edit an existing Thread Schedule.
Filtering Selector Window Lists
If you create a large number of a particular type of object, such as Jobs, you can filter the list displayed in the
selector window by typing the first few letters of an object in the Search field. This is much faster than scrolling
down the list. The Search field supports regular expressions and Oracle wildcards (such as %, &, and .).

Administration
If you are a Applications Manager administrator, you will be responsible for ensuring the system is up and running,
and that users can access the system. How much more you are responsible for will depend on the structure of your
IT shop. At the very least, you will probably be expected to:
• Ensure that the Applications Manager Automation Engine, Agents, RMI server, and Web server are up and
running.
• Provide Applications Manager User IDs and Logins to developers, production analysts, operations personnel,
network administrators and database administrators.
• Set the Automation Engine options.
You may also be responsible for one or more of the following:
• Defining Host and Database Logins
• Defining Output Devices
• Managing retention of Applications Manager records and report output
• Migrating Applications Manager objects between development, test, and production instances

Installing the Automation Engine, Agent, and Web Server

The Applications Manager installation program can install a complete working instance on a single machine. The
instance will include the following:
 Applications Manager 9.4.1

• Applications Manager Automation Engine

• Applications Manager Local Agent
• RMI (Remote Method Invocation) server to support the Automation Engine
• A Web server to "serve" the Java client to a PC or other workstation
Acceptable Configurations
All components can reside on a single machine, or they can be spread across several machines. The diagram
below shows all components on a single machine.

This diagram shows a more likely scenario where the Applications Manager Automation Engine, Local Agent, RMI
server, and Web server are all on one machine, and the Applications Manager database is on another machine.
 Applications Manager 9.4.1

Applications Manager Database

Applications Manager uses an Oracle database to store all object definitions. Before installing Applications
Manager, you must set up the Applications Manager database, giving it a specific set of grants. This is a relatively
easy procedure that your database administrator should be able to perform in a few minutes. The required grants
are documented in the Installation Guide.

Controlling Access to Applications Manager and its Objects

To access Applications Manager, each user must be assigned a User object. Usually the Applications Manager
administrator is in charge of creating the Users.
 Applications Manager 9.4.1

The login allows a User to enter the Applications Manager client. Once the User is in the client, access to objects
and to different areas of the product, often referred to as managers, is controlled by User Groups.
User Groups Are Important
User Groups control access to the Applications Manager and its objects. When you create a User, you assign one
or more User Groups to the User. You can think of User Groups as containers. After creating a User Group, you
add objects and Users to the User Group. Users have access to all the objects in the container.
It's important for you to give some thought to the User Groups that will best serve the security needs of your
organization. For example, if you are a very small shop, you may need only a few User Groups such as
administrator, developer, and operations. If you are a large shop, you may want to use a more extensive set of User
Groups such as: administrator, financial applications developer, sales inventory application developer, customer
relations application developer, network administrator, database administrator, operator, and production analyst.
Each User Group would give access to different parts of Applications Manager and to a different set of objects.
The top row in the image below illustrates three typical User Groups: programmer, operator, and end-user. The
image also shows two additional programmer User Groups: edit and non-edit. The two User Groups make it
possible to give programmers read-only access to some objects, and edit access to other objects.

The programmers would be assigned to both User Groups. For example, you might give programmers read-only
access to:
• Objects that ship with the product (such as system Jobs and Process Flows).
• Objects that might be created by an Applications Manager administrator (such as Output Devices).
• Objects that might be created by a database administrator (such as Logins).
 Applications Manager 9.4.1

• Certain objects such as Queues (to give access to the Explorer window).
On the other hand, you would give programmers edit access to the Jobs and Process Flows that they create.
By having the two User Groups, you have the flexibility to give a group of Users the access they require to
accomplish their Job. You would most likely want an edit and non-edit User Group for operators as well. End-users
may only require a single non-edit User Group because they would not be creating objects.
DBA User Group
When you first install Applications Manager, there is one User Group called "DBA" that is assigned to the default
User. The "DBA" User Group gives the default User access to all functions and objects in Applications Manager.
By logging in as the default User (see the Installation Guide for the default user name and password), you can then
define additional Users.

Controlling Access to Hosts and Databases

A common security breach in traditional operations environments is the need to hard code host and database
passwords into scripts used to run tasks. For example, if you are running an FTP task from a script, you have to
include the target Host Login and password. Or if you are running a program that accesses a database, you have
to hard code the Database Login and password. Applications Manager solves this problem with Login objects.
Logins Window
In Applications Manager, you can define Host and Database Logins using the Logins window. An example
Database Login is shown below.

An example Host Login is shown below.

Login Objects Used by Developers

The advantage of the Applications Manager Logins is that developers can use them without having to know the
host or database password. They simply select a Login from a drop-down list box
For example, when a developer defines a Job to run a task that must access a database, the developer can select
a Database Login as shown below.
 Applications Manager 9.4.1

You can control the Logins that are displayed in the list box by using Applications Manager User Groups. Only the
Logins that are included in a User Group assigned to the developer will be displayed. Security is maintained, and
the developer's task is made easier.
Encrypted Passwords
In both Host and Database Logins, the Login names are displayed as plain text, but the passwords are encrypted.
The only person who knows the password is the person who entered it in Applications Manager. This ensures a
high level of security.
Reduced Maintenance
By defining the Database and Host Logins as objects in Applications Manager, you can update a Login in one place
and have that change take effect everywhere the Login is used. This greatly reduces your maintenance time.

Managing Output
Applications Manager can capture output from any task it runs, send the output to any type of Output Device, and
make the output available for viewing online through the Applications Manager Java client.
 Applications Manager 9.4.1

Applications Manager includes a built-in output distribution function that can send output to almost any type of
Output Device including traditional printers, fax machines, plotters, and email. But Applications Manager also can
make the output available for online viewing directly from the Applications Manager client.

Output Device Objects

For Applications Manager to send output to an Output Device, you must define that Output Device as an object in
Applications Manager. When you have defined the Output Device, you can assign it to one or more Applications
Manager Jobs. If the Output Device changes, you only need to update the Output Device definition in Applications
Manager in one place.
Talking to Output Devices
When Applications Manager sends output to an Output Device such as a laser printer, it uses an Output Interface
script. The script builds the appropriate print command for the device. Writing the scripts is straightforward and is
typically handled by your network administrator.
Applications Manager ships with several Output Interface scripts already defined, including Output Interfaces for
UNIX, Linux, and Windows. Below is an example of the UNIX script that ships with Applications Manager:

file=$1
 Applications Manager 9.4.1

shift
eval "lp $* $file"
exit $?

As an Applications Manager administrator, you may define Output Devices in Applications Manager, or you may
provide access to a network administrator to define the device.
Online Viewing
When Applications Manager runs a task, such as an Oracle Applications or PeopleSoft task, it builds the
appropriate commands using an Applications Manager Program Type interface script. Also incorporated in the
script is the ability to register the output from the task and make it available instantly for online viewing. This
capability is an integral part of Applications Manager.
When determining how to make the best use of Applications Manager output management, you should examine
this ability to view output online and how it might affect how you currently distribute output.
Applications Manager interface scripts are available for the most popular enterprise applications, and Broadcom
Global Services Offerings services can create custom scripts for almost any application.

Retaining Output Files and Operations Records

The Applications Manager SYSTEM Process Flow deletes outdated output files and clears old records from the
history tables.
In today's post-Sarbanes/Oxley environment, retention policies are more important than ever for audit purposes.
You must be able to show that the tasks in a Process Flow executed successfully and produced the desired output.
As the Applications Manager administrator, you may be responsible for assuring that output files and history
records are being retained for the required length of time.
SYSTEM Process Flow
Output files and history records are purged by the Applications Manager SYSTEM Process Flow that ships with the
product. The Process Flow includes two Jobs:
• DELDEFAULT: purges output files based on settings in the Job definition
• HISTORY_PURGE: purges old history files based on parameters set in the HISTORY_PURGE Job
By default, the SYSTEM Process Flow runs every day at midnight. You can change the schedule to accommodate
your operations environment.
Output File Retention Set at the Job Level
In Applications Manager, when a developer defines a Job to run a program, the developer can choose how long to
retain the output files generated by the task. On the Output tab of the Jobs window, the developer can set:
• Retention days.
• Maximum number of revisions.
These two settings work together to determine how long output files are retained. Note that Applications Manager
will use the maximum number of revisions only if that option is set for the Automation Engine.
History Records Retention
History records are displayed in the Explorer window in the History pane as shown below. How long these records
are available for viewing in the History pane is determined by the prompt value set for the HISTORY_PURGE Job
in the SYSTEM process flow.
 Applications Manager 9.4.1

Archiving Records
The SYSTEM Process Flow purges output files and History records, but it does not archive the files or records.
If you wish to perform archive functions, consider building an archive Process Flow that executes the functions.
For example you could create a Process Flow that prints a report of the History records, moves the records to
an archival database, and moves the output files to an archival directory. This archival Process Flow could be
scheduled to run before the SYSTEM process flow.
You should never modify the SYSTEM Process Flow because it is reinstalled every time you upgrade or reinstall
Applications Manager. If you want to modify the SYSTEM Process Flow, copy it to another Process Flow, then
modify the copied Process Flow and run it instead of the SYSTEM process flow.

Setting Automation Engine Options

You can control the behavior of the Applications Manager Automation Engine by setting the Automation Engine
options.
When you install Applications Manager, there are a number of options set for the Automation Engine by default.
These options control a wide range of behaviors. The default settings represent the most common settings used by
Applications Manager customers.
If you want to change these options, you can do so from the Automation Engine Options tab for the Automation
Engine in the Agents window shown below.
 Applications Manager 9.4.1

Moving Objects from One System to Another

When you want to move Applications Manager objects from one system to another, you use the Export and Import
features. When importing, you can map objects, including objects that were not exported. You can save the map file
and use it for other imports.
If you are like many Applications Manager customers, you will maintain development, test, and production
instances of Applications Manager. This raises the issue of how to move Applications Manager objects created in
the development instance to the test and production instances. Migration from one machine to another is one of the
most error-prone tasks in the IT environment. Applications Manager provides export and import utilities that make
the process easy and reliable.
 Applications Manager 9.4.1

Moving Applications Manager objects from one instance to another is a simple three-step process:
1. Export the objects from the source machine.
2. Move the export file to the target machine.
3. Import the objects to the target machine.
Exporting Objects
To export objects, use the Exports window and build an export list. The list can include any number of objects. You
can export all Applications Manager objects except Agents, Agent Groups, Logins, and Users. When you select
an object, Applications Manager automatically identifies any supporting objects. For example, if you include a Job,
Applications Manager identifies any Output Devices assigned to the Job and gives you the opportunity to add the
Output Devices to the export list. You can save the export list and reuse it the next time you want to export objects.
After building the export list, you run the export program. The program generates the export file.
Moving the Export File
After generating the export file, you transfer the file from the source machine to the target machine.
Importing Objects
On the target machine, use the Imports window to import the objects from the export file. When you load the file
into the Imports window, support objects such as Agents, Agent Groups, Logins, and Users that could not be
included in the file will be flagged. You can then map these objects to corresponding objects on the target machine.
 Applications Manager 9.4.1

For example, suppose you are exporting from a development machine to a test machine. An exported Job was
defined to run on the DEV Agent. On the test machine, the corresponding Agent is TEST. You simply map the DEV
Agent to the TEST Agent.
When you have completed mapping the objects, you can save the map for repeated use, ensuring consistency.
To complete the process, you run the import. The objects are added to the target instance.

Development
As a developer, you will create objects used to define Jobs and run tasks. When we talk about development in
Applications Manager, we are referring to the creation of Jobs to run tasks, and the addition of Jobs to Process
Flows. If you are a developer, you will most likely:
• Create Jobs to run programs and scripts.
• Create Process Flows to run a series of Jobs.
• Add dependencies to Process Flow components to establish the correct execution order in Process Flows.
• Define Job parameters.
• Add IF - THEN logic to Jobs and Process Flows to ensure the correct conditions exist before they execute.
• Automate retrieval of values from databases to eliminate data entry errors.
• Schedule Jobs and Process Flows to automate production.
Objects
As you build Jobs and Process Flows, you will use a number of objects including:
• Applications to categorize Jobs and Process Flows
• Libraries to specify paths to programs
• Program Types to interface with programs and applications
• Database and Host Logins
• Substitution Variables to store values used in Job parameters
• Queues to control load on your systems
• Output Devices to distribute output
There are many other objects that you may use, or that may be used by the Applications Manager administrator or
operators.
Naming Conventions
You should put some thought into naming conventions for your objects because you cannot readily rename objects
in Applications Manager. This is not a problem if an object is not used in very many places because you can copy
the object, give it a new name, then replace the old object with the new object. But if you have used the object in
many places, copying and replacing is not practical.
Replacing Scripts with Jobs and Process Flows
One of the greatest returns on your investment in Applications Manager can be realized by replacing your scripts
with Applications Manager Jobs and Process Flows. Long scripts that have been used to run nightly batch
processing can be broken up, and each program run by the script can be replaced by a Job. Those Jobs can then
be combined to create a Process Flow that duplicates, or improves, the Job flow in the original script. Elements in
the script that handle output should be replaced by Applications Manager Output Devices.
If the scripts require manual intervention by operators, every attempt should be made to use Applications
Manager predecessors, conditions, and Substitution Variables to automate these manual steps. Predecessors
and conditions can ensure that the Jobs in a Process Flow execute in the correct sequence and that the correct
conditions have been met for the tasks to execute successfully. Substitution Variables can be used to automatically
enter values for parameters where the values are retrieved from your corporate database at the time of execution.
These three features (predecessors, conditions, and Substitution Variables) give you the power to automate
operations to a greater extent than is possible with any other distributed scheduler.
Scheduling
Depending on the size of your organization, you may be responsible for scheduling Jobs and Process Flows, or this
responsibility may fall to production analysts. Either way, Applications Manager has an extensive set of features
for scheduling Jobs and Process Flows. You should be able to create schedules that closely match your corporate
data processing procedures.
 Applications Manager 9.4.1

Creating Jobs to Run Programs and Scripts

A Job is an Applications Manager object that specifies all the information required to run a program or script. Jobs
are among the most important objects in Applications Manager. After you have defined a Job, you can:
• Run the Job manually from the Requests window.
• Run the Job on a set schedule.
• Add the Job to one or more Process Flows.
When Do I Need to Create a Job?
You need to create a Job when you want to run a program, application, or script from Applications Manager. For
example, you would create a Job to:
• Perform a data load.
• Run an Oracle GL import Job.
• Run a UNIX script.
• Execute an FTP.
• Run a report.
Basic Information Required to Create Jobs
The basic information required to create a Job is listed below:
• The name of the program or script to be run
• The name of the Program Type that will build the appropriate command to run the program or script
• The name of the Applications Manager Agent where the program or script will be run
• If required, a host or Database Login
• If required, prompts to define the parameters required to run the program or script
• The Output Device or devices that will receive the output generated by the program or script
The General tab for a sample Job is shown below. Note the additional tabs where you would enter other
information such as Output Devices, Logins, schedules, prompts, predecessors, and conditions.
 Applications Manager 9.4.1

The Role of Program Types Scripts

You must assign a Program Type to every Job you create. Behind the Program Type is an interface script that tells
Applications Manager how to run the Job. The script:
• Builds the command that executes the program.
• Passes any parameters required to run the program.
• Detects errors generated by the program.
• Registers the output generated by the program so it can be printed by Applications Manager and viewed online
through the Applications Manager client.
• Terminates the program.
Applications Manager ships with, or has available as extensions, a number of Program Types and matching
Program Type scripts including:
• UNIX and Windows shell scripts
• Java programs
• SCT Banner
• SQL*Plus programs
• Oracle
• PeopleSoft
If you need to run a custom application or a third-party application, you will need to create a new Program Type
and matching Program Type script. The Development Guide gives detailed information on creating Program Type
scripts. Broadcom also offers consulting services to create the scripts.
 Applications Manager 9.4.1

Creating Process Flows to Run a Series of Jobs

If you are using scripts to run your nightly batch processing, review those scripts to see how you can convert
them to Jobs and Process Flows. Long scripts that have been used to run nightly batch processing can be broken
up, and each program run by the script can be replaced by a Job. Those Jobs can then be combined to create a
Process Flow that duplicates, or improves, the Job flow in the original script.
If the scripts require manual intervention by operators, every attempt should be made to use Applications
Manager predecessors, conditions, and Substitution Variables to automate these manual steps. Predecessors
and conditions can ensure that the Jobs in a Process Flow execute in the correct sequence and that the correct
conditions have been met for the tasks to execute successfully. Substitution Variables can be used to automatically
enter values for parameters where the values are retrieved from your corporate database at the time of execution.
These three features (predecessors, conditions, and Substitution Variables) give you the power to automate
operations to a greater extent than is possible with any other distributed scheduler.
Example Process Flow
For example, suppose you have a script that executes the following steps:
1. Purge data
2. FTP data from mainframe
3. Load data
4. Cleanse Data
5. Run three reports against the data
6. Perform a GL import
7. Perform a GL post
In Applications Manager, you might create a Process Flow that would look like the following.

Notice that each step is completed sequentially. The three reports are run as a sub Process Flow, and are
processed simultaneously. However, the GL_IMPORT step will not execute until the three reports have run.
Process Flow Size
How large should you make a Process Flow? There are no hard and fast rules. A Process Flow may contain
up to 999 components. A component can be a Job or another Process Flow. When you add a Process Flow to
another Process Flow, it is considered a sub Process Flow. Sub Process Flows can include their own sub Process
Flows. While you can sub Process Flow to 32 levels, three levels of sub Process Flows is sufficient for most
implementations.
 Applications Manager 9.4.1

Below are some guidelines to help you decide how large to make a Process Flow:
• If your entire nightly batch processing centers around one application, and each Job is tightly integrated with the
other Jobs, you could run your entire nightly batch processing from one single Process Flow.
• If you have several processing runs that deal with different applications with no interaction, you might consider
creating a Process Flow for each application. Each Process Flow could be scheduled to run at a set time during
the batch processing window.
• If you are running nightly batch processing that involves multiple applications with many interrelated Jobs, you
might create a number of sub Process Flows, then add those sub Process Flows to one main nightly batch
processing Process Flow scheduled to run at the beginning of your batch processing window.
• If you are modeling a Process Flow that is used in several different batch processing sequences, you may want
to create the flow as a separate Process Flow that you can then add to several other larger Process Flows. This
takes advantage of the fact that Process Flows are reusable objects in Applications Manager. If the Process
Flow changes, you can make edits to the Process Flow in one place and they will take effect everywhere the
Process Flow is in use.
To a great extent, whether you use a few large Process Flows, or create many smaller Process Flows will depend
on the preferences of your operations group. Applications Manager can accommodate both approaches.
Managing Large Process Flows
If you choose to create large Process Flows, sub Process Flows and groups can help you manage them. Both
sub Process Flows and groups can be expanded and collapsed to show and hide their components. Collapsing
sub Process Flows and groups can make it easier to see the big picture in a large Process Flow. The image below
shows a collapsed sub Process Flow called DATA_REPORTS.

In contrast to sub Process Flows that are independent objects added to a Process Flow, groups are created within
a Process Flow from components that already exist in the Process Flow. Groups are used to manage collections
of components. For example, groups can display parallel flows in a Process Flow more clearly. Groups, like sub
Process Flows, can be collapsed to save real estate in the Process Flows window. Unlike sub Process Flows,
groups are not independent objects. They exist only with the Process Flow where they are created and you cannot
copy or reuse them.

Adding Dependencies to Jobs

In Applications Manager, execution order of components in a Process Flow is determined by dependencies. You
define dependencies by adding predecessor links between components. By default, when you add components to
a Process Flow using the drag-and-drop method, Applications Manager automatically adds success predecessor
links between the components. The result is that you can quickly and easily build simple Process Flows similar to
the one shown below.
 Applications Manager 9.4.1

You also can add predecessor links to standalone Jobs. In this case, the links identify other tasks that must
complete before the standalone Job will execute.
Internal vs. External Predecessor Links
The Process Flow shown above relies on internal predecessors links, which means all links are contained within
the parent Process Flow, in this case NIGHTLY_PRODUCTION. But what if a step in this Process Flow was
dependent on a step in another Process Flow completing successfully? You would need to create an external
predecessor link as shown below. The link goes from the FTP Job in the NIGHTLY_PRODUCTION Process Flow to
the CK_DISK Job in the External References box.

Types of Predecessor Links

There are several types of internal and external predecessor links. They are described briefly below.
• Success (default)
 Applications Manager 9.4.1

The predecessor component has completed successfully.

The Applications Manager success logic is quite sophisticated; there are other scenarios which cause success
requirements to be satisfied. See the Development Guide for more details.
• Started
The predecessor component has started or has been skipped in this run of the process flow.
• Complete
The predecessor component has completed processing. The actual status does not matter.
• Success since last run
The predecessor component has completed successfully since the last time the Job ran. This link type is only
available for external predecessors. It is useful for Process Flows that run multiple times a day.
• Success (skip on failure)
The task runs if the predecessor runs successfully, but skips if the predecessor fails. This type of predecessor is
often used for branching logic along with the Failure (skip on success) predecessor described below.
• Failure (skip on success)
The task runs if the predecessor fails, but skips if the predecessor runs successfully. This type of predecessor is
often used for branching logic along with the Success (skip on failure) predecessor described above.
• Success only when FINISHED
The predecessor runs and goes into a FINISHED status. This link type is only available for external
predecessors. If the external predecessor is deleted, it will not satisfy the predecessor link requirements.
• Failure
The predecessor fails.
Note that predecessor logic in Applications Manager can be complex. You should thoroughly study the predecessor
chapter in the Development Guide before beginning to create Process Flows.

Passing Parameters to Programs and Scripts

Prompts pass parameters to a program or script run by a Job.
If you are creating an Applications Manager Job that runs a program or a script that takes one or more parameters,
you must create prompts for the Job. For example, the employees.sql script shown below runs a report of
employees for a department. The script has one variable dept_name shown in bold.

set verify off

set feedback off
set termout off
spool &so_outfile
column ename heading 'Employee|Name'
column dname heading 'Dept|Name'
select emp.ename, dept.dname
from emp, dept
where dept.dname = '&dept_name'
and emp.deptno = dept.deptno;
spool off

While creating the Job to run this program, you would include a prompt where the department name could be
entered. The image below shows an FTP Job that takes seven parameters:
 Applications Manager 9.4.1

Types of Prompts
There are four types of prompts you can create. The type of prompt determines how the information is entered. The
different types of prompts are described below.

Prompt Type Description

Default The prompt has a default value that users are not
allowed to change. Use this type of prompt when the
parameters for a Job do not change frequently.

Fill-in The prompt may or may not have a default value.

Users are allowed to change the value. Use this type of
prompt when you do not want to retrieve the value from
a database.

Single selection from a list Users may select one (and only one) choice from a
predefined list of possible values. The values can
be pulled from any database table. Use this type of
prompt when end-users will be running the Job from
the Requests window and you want to avoid data entry
errors.

Multiple selection from a list Users may select one or more choices from a
predefined list of possible values. The values can
be pulled from any database table. Use this type of
prompt when end-users will be running the Job from
the Requests window and you want to avoid data entry
errors.

Sources for Prompt Values

When you define a prompt for a Job, there are several ways values can be entered for the prompt:
• When you define the prompt, you can enter a default value. The default value will be used whenever the Job is
run if no other value is supplied. For most Jobs that will be included in a Process Flow, you will want to enter a
default value.
• When you define the prompt, you can enter an Applications Manager Substitution Variables as the default
value. The Substitution Variables pulls a value from a database at the time the Job is executed. For example, a
program may require today's date as one of its parameters. You can enter the Substitution Variables #today as
the default prompt value. When the Job is run in a Process Flow or from the Requests window, today's date will
automatically be filled in for the prompt. This is a very powerful feature in Applications Manager that makes full
automation of your Process Flows an attainable goal.
• If you run the Job from the Requests window, you can enter a value for the prompt. If you have end-users
running tasks from Applications Manager, being able to enter values allows them to customize the tasks. You
 Applications Manager 9.4.1

can even define the prompt using a SQL query that will pull a list of values from a database table and present
them to a user when they run the Job from the Requests window. For example, a user could run a sales report
and select their region from a list. By selecting values from a list, you eliminate the possibility of a data entry
error.
• If you add the Job to a Process Flow, prompt values for the Job can be retrieved from the Process Flow header
using special numbered Substitution Variables. This means you can enter one set of values in the Process Flow
header, run the Process Flow using those values, then enter a second set of values and run the Process Flow
again. The entire process can be automated so that the sets of values are pulled from rows in a database table.
The Process Flow is run once for every row in the table. This technique is particularly useful for running Oracle's
Multi-Org.

Adding IF - THEN Logic to Jobs and Process Flows

One of the way Applications Manager is a truly intelligent scheduler is by using conditions. Conditions are "if...
then" statements that you can add to Jobs, Process Flows, and Process Flow components to control execution of
those objects. Some examples include:
• If JOB_ABC has completed successfully, run JOB_XYZ.
• If the current time is later than 4:00 A.M., put JOB_ABC on hold and notify operations.
• If there are fewer than 100 transactions in the sales database, delay sales processing for 30 minutes and check
again.
• If a task has been waiting in the Backlog for more than 30 minutes, switch it to a higher priority Queue.
You can add as many conditions to a Job or Process Flow as you wish. If you have not added conditions to the
Jobs in a Process Flow, the Jobs will execute sequentially based solely on the predecessor links.
Defining a Condition
To define a condition, you select the timing, the type of condition, the test, and the action. An example of a
CHECK FILE condition is shown below.

In the example above:

• The condition is checked BEFORE the task is run.
• The condition type is CHECK FILE.
• The test checks for any file with a .rep extension in a particular directory on the Agent machine.
 Applications Manager 9.4.1

• The action taken is to delay the task by five minutes and run the check again.
When to Use Conditions
Conditions are an optional feature in Applications Manager. You can create a Process Flow and add Jobs to it, and
the Jobs will execute in the order they are displayed in the Process Flow. Schedule the Process Flow to run on
certain days at a specific time, and you are ready to go. It's quick and easy to build and schedule such a Process
Flow, and it may be all you need.
But you will want to add conditions to the components in a Process Flow if you want to synchronize the Process
Flow with events taking place outside of the Process Flow. For example:
• Run a Process Flow a second time when a certain Job in the Process Flow completes. In other words, the two
runs of the Process Flow will overlap, with the second run starting based on completion of a specific Job in the
first run.
• Run a Process Flow only when a certain number of records exist in a database table.
• Run a Process Flow at 10:00 P.M., but ensure that a specific component in the Process Flow does not run until
after midnight.
• Run a Process Flow only if the Job XYZ completed within the last two days.
Jobs, Process Flows, and Process Flow Components
You can add conditions to standalone Jobs, to Process Flows, and to Jobs and Process Flows within a Process
Flow. This gives you a great deal of flexibility in controlling execution of tasks in Applications Manager.
Before, During, and After Conditions
You can create conditions that are checked before, during, or after a Process Flow or component executes. For
example, for one Job in a Process Flow you might create:
• A BEFORE condition that checks if a specific data file exists.
• A DURING condition that sends an email Notification to operators if the task is running too long.
• An AFTER condition that changes the status from FINISHED to FINISHED WITH ERRORS based on the
return code.
You can add as many conditions as you need to control the execution of Jobs and Process Flows.

Retrieving Values from Databases

Substitution Variables store values that can be used in prompts and conditions in Jobs and Process Flows. The
values can be stored in a database table or generated by a SQL statement at the time a task is submitted.
Imagine if you could eliminate data entry errors by automatically retrieving parameter values from your corporate
database. And what if you could control the execution of tasks based on information stored in your corporate
database. Applications Manager Substitution Variables make it possible to do both.
What are Substitution Variables?
In Applications Manager, Substitution Variables are objects that store values. The values can be fixed or dynamic.
Dynamic variables retrieve values from a database using a SQL statement. For example, the Substitution Variables
shown below uses a SQL statement to retrieve the number of employees listed in the EMP table. The Substitution
Variables is called #count_employees.
 Applications Manager 9.4.1

Eliminating Data Entry Errors

Data entry errors are some of the most common mistakes made in operations. In Applications Manager, you can
eliminate these errors by using Substitution Variables to enter parameter values. For example, the image below
shows a report that must be run using the first and last day of the month as its parameter values. The Substitution
Variables #yesterday and #today are being used to fill in the start and end dates.
 Applications Manager 9.4.1

Controlling the Execution of Tasks

Once you define a Substitution Variables, you can use it in a condition statement to control the execution of a task.
In the image below, a condition statement delays the execution of the EMPLOYEES_REPORT Job 30 minutes
every time the #count_employees Substitution Variables returns a value less than 50. When the value exceeds 50,
the Job executes.
 Applications Manager 9.4.1

Scheduling Jobs and Process Flows

With Applications Manager, you can create schedules to run Jobs and Process Flows that account for days of the
week, specific days of the month, days in a Calendar, workdays, and fiscal Calendars.
After creating Jobs and Process Flows, you can schedule them to run automatically. You can schedule individual
Jobs as well as Process Flows. Applications Manager can accommodate just about any scheduling requirement
from the simplest to the most complex. For example:
• Run Monday through Friday at 1:00 A.M and 2:00 P.M.
• Run once an hour on the half-hour from 8:00 A.M. to 5:00 P.M.
• Run on the last Friday of the month.
• Run only on holidays.
• Run Monday through Friday except on holidays.
• Run on the first workday of the month based on a fiscal Calendar.
You create schedules for each Job and Process Flow that you want to automate. Unlike the other objects in
Applications Manager, schedules belong to a specific Job or Process Flow and cannot be assigned to other Jobs
and Process Flows.
Scheduling Intervals
When you create a schedule, you can choose from a wide range of units as shown below.
 Applications Manager 9.4.1

Multiple Schedules
You can create more than one schedule for a Job or Process Flow. For example, if you want a Process Flow to run
Monday through Friday at 1:00 A.M., and Saturday at 8:00 A.M., you can create two schedules. You can review the
schedules using the 12 Month Display shown below.
 Applications Manager 9.4.1

Scheduling with Calendars

You can build Calendars in Applications Manager and use them as run dates or as skip dates. For example, you
can create a Calendar of holidays and use it as a run Calendar or as a skip Calendar. Unlike schedules, Calendars
can be reused with any number of Jobs and Process Flows.
You can build Calendars one day at a time, or use rules. Rules are useful when you want to add dates such as the
5th work day of the month, or the first or last workday of the month.
Along with traditional Calendars, you also can create fiscal Calendars to better match your corporate business
model.
Setting Eligibility in Process Flows
When you schedule a Process Flow, the entire Process Flow is launched at the specified date and time. However,
you can choose not to run individual components in a Process Flow on specific days of the week, to run only on
dates in a Calendar, or to skip on dates in a Calendar. This provides an additional level of control over schedules.
 Applications Manager 9.4.1

Running a Custom or Third-Party Application

To run a custom or third-party application, you define an Applications Manager interface script and matching
program type.
When you define a Job to run a program or script, you assign it an Applications Manager Program Type. A Program
Type is an Applications Manager object that calls an interface script. The interface script provides the bridge
between Applications Manager and the target program. The script:
• Builds the command that executes the program.
• Passes any parameters required to run the program.
• Detects errors generated by the program.
• Registers the output generated by the program so it can be printed by Applications Manager and viewed online
through the Applications Manager client.
• Terminates the program.
The image below shows an example of an Applications Manager Job using an INVENT Program Type.

The INVENT Program Type calls the INVENT interface script, which in turn runs the XYZ task in the Inventory
custom application.
 Applications Manager 9.4.1

Applications Manager ships with, or has available as add-ons, Program Types and their matching interface scripts
to run some of the more common programs including:
• Java programs
• SCT Banner
• COBOL
• UNIX and Windows shell scripts
• SQL*Plus programs
• Oracle
• PeopleSoft
If you want to run a custom application, or a third-party software program, you must write an Applications Manager
interface script. The advantage of writing an interface script is that once it is written, you can use it to run an
unlimited number of tasks in the target application or program. This is in keeping with the Applications Manager
object-oriented approach to development.
The Development Guide documents how to create Program Type interface scripts. Applications Manager also
offers consulting services to create the scripts.
Sample UNIX Program Type Script
Below is a listing of a sample EXEC Program Type script used to run UNIX shell scripts. The line numbers have
been added for reference and do not appear in the actual script.

1 :
2 #!/bin/sh
3 #copyright 2009 by Automic Software GmbH
4 # $Header:
/isa/devel/soport/so/dev/sostage/RCS/EXEC-EXECS,v
1.2 2004/02/24 19:06:46 billw Exp $
5 arg="$program `$SQLOPER_HOME/exec/ONELINE $par`"
6 eval $arg
7 err=$?
8 if [ -f $file ]; then
9 $AW_HOME/exec/FILESIZE $file $err
10 err=$?
11 fi
12 if [ -f $OUTPUT/$file ]; then
13 file=$OUTPUT/$file;export file
14 $AW_HOME/exec/FILESIZE $file $err
15 err=$?
16 fi
17 exit $err

The table below lists the key functions a Program Type script must perform, and the corresponding lines in the
EXEC program.

Function Line(s) Notes

Program execution 6 Accomplished with the eval

command. Note that arg includes
the $program variable.

Parameter passing 5 Accomplished with ONELINE and

$par.
 Applications Manager 9.4.1

Function Line(s) Notes

Error determination 7, 10, 15, 17 The code err=$? traps the exit
status of the last command
executed.

Output registration 9, 14 Accomplished by FILESIZE.

Debug/administration --- Not present in this script.

Termination 17 Accomplished with exit command.

$err traps exit code.

Getting Notified when a Task Fails

Applications Manager includes a Notification object that alerts you to unusual task runs.
If you are an operations-intensive shop, you will be monitoring Applications Manager through the Explorer window.
If you are more of a "lights out" shop, no one will be monitoring Applications Manager. You will want to be notified
when a task does not complete as expected, or perhaps that a task has completed on time, letting you know that
your batch production run is on schedule. Both types of Notification are handled by the Applications Manager
Notification feature. You can receive Notifications by email, page, or any other type of device.
You define Notifications in Applications Manager, then assign them to Process Flow components, Jobs,
Applications, and Program Types. Details from a sample Notification definition are shown below.
 Applications Manager 9.4.1

Versatility
When you define a Notification, you can enter multiple details covering a variety of conditions. For example, you
can enter one detail that sends out an email when a task finishes. The message could read:

"Task <job name> finished on <date> at <time>."

where <Job name>, <date>, and <time> are filled in for each particular task.
 Applications Manager 9.4.1

You could enter a second detail that sends out a pager message when a task fails. The message could read:

"<job name> on <agent> failed at <time>"

By using the variables in the messages, the Notification object can apply to any task.
Assigning Notifications
After you have defined a Notification, you can assign it to Process Flow components, Jobs, Applications, and
Program Types. Being able to assign Notification objects to Applications and Program Types makes it easy to set
up Notifications for a whole class of Jobs.

Detecting Failed Tasks by Scanning Output

Output Scans are Applications Manager objects used to scan output for text strings that indicate if a task has failed
or succeeded. They are assigned to Jobs and Program Types. Each Output Scan includes one or more rules.
Some programs can complete, executing successfully, but not accomplish their intended work. For example, an
Oracle report may execute correctly, but return bad data. The only way to tell if the report content is correct is to
parse the report text. If the error occurs at the beginning of a Process Flow, all subsequent processing may be
incorrect. The error may not be detected until the entire Process Flow is done processing, leaving no time to rerun
the Process Flow within the processing batch window.
Output Scans
Output Scans are Applications Manager objects used to scan output for text strings that indicate if a task has failed
or succeeded. They are assigned to Jobs and Program Types. A rule from an example Output Scan is shown
below.
 Applications Manager 9.4.1

Each Output Scan includes one or more rules. To use an Output Scan, you:
• Define the Output Scan object.
• Add rules to the Output Scan.
• Assign the Output Scan to one or more Jobs and Program Types.

Operations
As an operator, you will monitor tasks as they run through Applications Manager.
Applications Manager provides robust operations tools through the Explorer window. From Explorer, you can:
• Monitor the system.
• Run tasks on an as-needed basis.
• Find out what tasks will run during your shift.
• Troubleshoot tasks.
• Take actions on tasks.
• Handle exceptions to normal processing.
• View and print task output.
• Control load on the system.
• Prevent Applications Manager from launching tasks.
 Applications Manager 9.4.1

Monitoring the System

As an operator, one of your key responsibilities will be to monitor the tasks running through Applications Manager.
You monitor the Applications Manager system using the Explorer window shown below.

The Explorer window includes three panes and a status bar. The pane on the left displays a navigational tree.
The item you select in the navigational tree determines what is displayed in the top right pane of the window. The
bottom right pane always displays the History.
The Backlog and History
When a task is submitted in Applications Manager, it is sent to the Backlog. Tasks remain in the Backlog until they
complete successfully or are deleted. Selecting Backlog from the navigational tree displays in the top right pane all
tasks in the Backlog.
 Applications Manager 9.4.1

When a task completes executing, Applications Manager removes it from the Backlog and writes a record to the
History. Applications Manager also writes records to the History when tasks are killed or when they fail with a status
such as ABORTED.
Taking the Pulse of the System
The status bar runs across the bottom of the Explorer window and provides status at a glance. Its color reflects
the most severe status of the Applications Manager Automation Engine and Agents, and the tasks running in the
Backlog. The status bar colors have the following meaning:

Color Description

Green All tasks, Automation Engines, and Agents are running

satisfactorily.

Yellow One or more tasks are on hold.

If there are aborted tasks and tasks on hold, the aborted
tasks take precedence and the status bar will be red.

Red One or more tasks have aborted, or the Automation

Engine or an Agent has a BUSY or TROUBLE status.

When the Explorer window is minimized, the button on the taskbar uses the same color scheme.
Using the Explorer Tree Icons
The navigation pane on the left side of the window provides a tree structure with selectable object icons. When you
select an icon, Applications Manager displays the matching information in the top right pane of the window. The
pane can show:
• The Backlog (tasks waiting to be processed).
• A filtered list of tasks in the Backlog.
• A summary of objects selected in the object tree.
• Tasks in a particular Process Flow.
Viewing Components in a Process Flow
The Explorer tree displays Process Flow components alphabetically to help you find them. When you select a
Process Flow in the Explorer tree, those same components are displayed in the top right Explorer pane according
to your Backlog search criteria. The default sort method is by task status. To view a flow chart of the Process Flow,
right-click the Process Flow icon and select Predecessors.
Sorting Columns
You can sort any of the columns in the Explorer window to help you find tasks. For example, you can click on the
Status column header in the Backlog to display three different sort orders: ascending (alphanumeric), descending
(alphanumeric), and severity of status. When you sort tasks by severity of status, Applications Manager lists the
most severe task statuses first.

Finding Out Which Tasks Will Run During Your Shift

With the forecast feature you can view a list of scheduled Jobs and Process Flows.
If you need to see a list of scheduled tasks, the Forecast window shows them to you. Data is loaded into the
Forecast window by running an Applications Manager Job called FORECAST. The FORECAST Job is usually run
with a schedule, but can be requested to show recent updates.
 Applications Manager 9.4.1

Each scheduled Job/Process Flow includes the start date and time and the Job or Process Flow's name. Process
Flows also include a key icon used to expand/collapse them. To create a basic run book, you can print the current
view of the Forecast window.
Production Schedule
If the forecast does not provide enough detail, you can run a Production Schedule report. Part of a sample
Production Schedule report is shown below.

Skip {Process Flow}Report Name

---- ----------------------------------------------------
Saturday Feb 23 2002 00:00
{SYSTEM}Saturday Feb 23 2002 00:00
{SYSTEM}DELDEFAULT
NDOW {SYSTEM}HISTORY_PURGE

Monday Feb 25 2002 00:00

{SALES_REPORTS}Monday FEB 25 2002 00:30
{SALES_REPORTS}REGION_A
B If CURRENT TIME > 06:00:00 then SKIP TASK
{SALES_REPORTS}REGION_B
B If CHECK FILE NO /reports/region_b.dat
{SALES_REPORTS}REGION_C
 Applications Manager 9.4.1

The report shows all tasks that are scheduled to run, tasks that will be skipped because of the day of the week, and
the conditions assigned to each component in a process flow.
Staging Tasks
A third way to find out which tasks are scheduled to run is to "stage" tasks. By default, the Backlog pane in Explorer
only shows tasks whose run date and time have been reached. Therefore, a task that is scheduled to run an
hour from now will not be displayed in the Backlog. You can override this default behavior by staging tasks to the
Backlog ahead of schedule. To stage tasks, you run the STAGING Job. Whether or not you use the staging feature
will depend on how your operations group functions.
If you are strictly a lights out shop, there is little need to stage tasks. You would not schedule the STAGING Job.
In the rare cases when you need to make changes to a task, you would run the STAGING Job ad hoc for that
task only.
If you are an operations-intensive shop, you may want to stage tasks on regular basis by scheduling the STAGING
Job. You can create a schedule that meets your operations requirements. For example, you could stage all tasks
scheduled to run over the next 12 hours.

Troubleshooting Failed Tasks

Applications Manager provides tools for troubleshooting failed tasks.
If a task fails, you need to respond quickly, correct the problem, and get processing back on track. Applications
Manager displays failed tasks at the top of the Backlog pane in Explorer, places a red "X" over the Backlog icon in
the navigation tree, and turns the status bar red.
 Applications Manager 9.4.1

Troubleshooting Failed Tasks

In Applications Manager, a failed task is usually assigned an ABORTED status. It is displayed in red and brought
to the top of the Backlog display. Applications Manager captures the system file generated by the aborted task
and makes it available for viewing online. The system file is an excellent place to start troubleshooting. Along with
 Applications Manager 9.4.1

runtime information and parameters passed to the task, the file includes error messages. A sample system file is
shown below.
To view system files, you right click the task in the Backlog or History, select Output, and select the system file.
Applications Manager displays the file in the Applications Manager file viewer. From the viewer, you can print the
file.
You can also view task details by right-clicking the task in the Backlog or History and selecting Task Details. Task
details show you various Applications Manager settings associated with a task. From a task's details you can view
the standard out file for a failed task to help determine what went wrong.
 Applications Manager 9.4.1

Getting More Detail with the Debug Utilities

If the system log does not provide enough information to solve the problem, you can use the Applications Manager
debug utilities. These give detailed information about every action taken by the system. If you find that you need to
use the debug utilities, you should contact Braodcom Support.
 Applications Manager 9.4.1

Handling Task Exceptions

To handle exceptions, you stage the task in question, then make changes to it from the Backlog.
Even in the most automated shops, there will be exceptions that must be handled. In Applications Manager, you
handle exceptions by staging the task to the Backlog in Explorer, then making changes to the task.
In Applications Manager, we define exceptions as any manual actions taken outside the normal batch cycle. They
include the following:
• Deleting a task in a Process Flow on a particular day.
• Removing a check for a file on a task.
• Removing a task's predecessor requirements.
• Changing a task's Database Login.
• Changing a task's prompt values.
Staging a Task
In normal operations, Applications Manager does not place a task in the Backlog until its scheduled run time. For
example, if a task is scheduled to run at 1:00 A.M., it will not show up in the Backlog until 1:00 A.M. This can make
it difficult to make changes to the task.
To get around this default behavior, you can stage the task. When you stage a task, Applications Manager places it
in the Backlog at the bottom of the display with a DATE PENDING status. You can then make the required changes
to the task. Taking actions on tasks is described in the next topic.
To stage a task, run the STAGING Job from the Requests window. When you run the Job, you can select the
Process Flows and Jobs you want to stage, and the number of hours in the future you want to stage.

Taking Actions on Tasks

You can take actions on tasks in the Backlog. After an action is taken a task log is written to document the action.
 Applications Manager 9.4.1

Putting Tasks On Hold

If a task is in the Backlog but has not yet started, you can put it on hold. The task will remain in the Backlog with a
status of HOLD until you reset it or delete it from the Queue. If a task has started running, you cannot put it on hold.
However, you can kill a running task.
Killing Tasks
If a task is running, you can kill it by selecting the task and using the Kill command. When you kill a task, it stays in
the Backlog until you delete it, or reset it. When you kill a task, Applications Manager makes an entry in the History
showing the task was killed.
Resubmitting Aborted, Killed and On Hold Tasks
If a task aborts and remains in the Backlog, is killed, or is put on hold, you can resubmit it directly from the
Explorer window. Before restarting a task, you can review its parameters, prompts, and conditions, and correct
any problems. When you restart an aborted task, its status changes to LAUNCHED. As soon as a thread becomes
available in the Queue, the status changes to QUEUED.
Deleting Tasks
 Applications Manager 9.4.1

If a task in the Backlog is in a non-running status, you can delete it. For example, tasks with a status of SELF WAIT,
ABORTED or KILLED can be deleted. When you have deleted a task, you cannot reset it directly from the Explorer
window.
Removing All Predecessors for Tasks
If a task in the Backlog is waiting for one or more a predecessors before it can run, you can remove the
predecessor(s) to force it to run.

Viewing/Editing Task Details

As you monitor tasks, troubleshoot failed tasks, and handle exceptions, you may find it useful to view detailed
information about a task. You can view all task details online by right-clicking a task in the Backlog (or History), and
selecting Task Details. Applications Manager displays the window shown below with tabs to select the information
you want to view.

Editing Details for Tasks in the Backlog

You can view and edit the task details on the various tabs of any non-running task in the Backlog from the Task
Details window. When you edit a task in the Backlog, you are editing that run of the task only. You are not editing
the Job's definition.
Editing Task Details for Tasks not Yet in the Backlog
 Applications Manager 9.4.1

If a task is scheduled to run at a later time, you can stage it so it is put into the Backlog. Once a task is staged you
can view and edit its task details.
Entering Comments
When you take an action on a task in the Backlog, a comment is automatically created by Applications Manager.
If you wish to include additional information, you can include your own comments to provide relevant information
about the processing of a task and why you made changes to the task.

Running Tasks Outside the Batch Cycle

You can run individual tasks or Process Flows from Applications Manager on an as needed basis. When requesting
Jobs and Process Flows, you can set various options to control how they run.
When you need to run a task outside of the batch cycle, or you need to run a task during the development cycle
to test it, you can request the task from the Requests and Submit windows shown below. Requesting a task
manually has no impact on the regularly scheduled running of the task.
 Applications Manager 9.4.1

Passing Values to Parameters in Programs or Scripts

If a Job or Process Flow includes prompts that allow you to pass vales to parameters in programs or scripts, you
can set their values in the Submit window.
Post-Dating Requests
 Applications Manager 9.4.1

If you want to run a task at a later time, you can post-date its start date and time.

Viewing and Printing Task Output

If a task generates output files such as a report, you can view the report online from Applications Manager. For
operations, this can be useful for confirming that the report format is correct or when you are troubleshooting a
task. Likewise, developers can check report output during development without having to physically print the report.
Applications Manager 9.4.1
 Applications Manager 9.4.1

If end-users submit ad hoc reports, they too can view the output files online, and print or email them. Many
companies use the online viewing feature to replace physical distribution of reports.
How to View Reports
Viewing reports online is as easy as right clicking the task in the History and selecting Output Files. You then can
select the report file or the system file and display it in the File Viewer window as shown above.
Viewing Output in Other Applications
If a task generates output in a format specific to an application such as Microsoft Word or Excel, you can configure
Applications Manager to open the file in that application.

Controlling Task Priority and Load on the System

Queues control the flow of tasks through Applications Manager. You use Applications Manager to level task loads
by setting the maximum number of threads for a Queue.
Balancing system demands and system resources is always an ongoing battle for IT. This has become even more
challenging with the increasing demand from Web-based online applications that produce activity spikes at different
times during the day. Applications Manager helps you manage the load on your system with Queues and priorities.
Controlling Machine Workload
All tasks must pass through an Applications Manager Queue to be executed. The main function of a Queue is to
limit the maximum number of concurrently running tasks. For example, assume a system runs best when no more
than 100 tasks are running at the same time. If left unchecked, far more than 100 tasks will run between 7:00 A.M.
and 5:00 P.M. By setting the Queue limits to a total number of 100 concurrent tasks, you can level the load and still
execute all tasks within a timely manner without overloading the system.

You can define as many Queues as needed to manage the load on your system. For example, you may define:
• A batch Queue that accommodates your nightly batch run.
• A high priority express Queue that handles management report requests.
• A low priority Queue that handles field report requests that are not urgent.
Setting Task and Queue Priority
When you define a task, you can assign it a priority. Applications Manager uses the priority setting to determine
which tasks in a Queue should be executed first.
Likewise, you can assign priorities to Queues. Tasks in a higher priority Queue will be executed before tasks in a
lower priority Queue. To ensure that tasks in a low priority Queue will not be shut out completely, you can reserve
threads on a Queue.
Do You Need to Worry About Queues?
Whether you need to be concerned about Queues and priorities depends on the size of your operation. If you are
a small shop running a couple of dozen tasks a day, one Queue may be all you need. On the other hand, if you are
a large shop running several hundred or several thousand tasks a day, you should spend time determining your
system requirements and defining Queues and priorities. The goal is to maximize use of your computing resources
without overloading them, and to ensure that you meet your service level agreements.

Preventing Applications Manager from Launching Tasks

You can put all task processing on a machine on hold by idling its Agent or put all tasks in a Queue on hold by
inactivating the Queue.
If you need to stop processing tasks, you have several options in Applications Manager.
• If you need to stop processing all tasks, you can idle the Applications Manager Automation Engine.
• If you need to stop processing tasks on a single Agent, you can idle the Agent.
• If you need to stop processing tasks through a particular Queue, you can inactivate the Queue.
You can easily idle an Automation Engine or Agent, or inactivate a Queue from the Explorer window. The image
below shows an Agent being idled.
 Applications Manager 9.4.1

The image below shows a Queue being inactivated.

 Applications Manager 9.4.1

When you idle an Automation Engine or Agent, or inactivate a Queue, currently running tasks will complete, but any
tasks waiting will not start.
Resuming an Automation Engine or Agent
If you want to stop processing newly submitted tasks through an Automation Engine or Agent you can idle it. The
Automation Engine/Agent will go to an Idled status and the icon for the Automation Engine/Agent will be displayed
with a yellow triangle over it in the Explorer tree. Tasks in the Backlog set to run on an Agent in an Idled status will
have a task status of AGENT WAIT. To take the Automation Engine/Agent out of the idle status, you resume it.
Activating Queues
If a Queue is inactive, Applications Manager will still submit scheduled tasks to the Queue but they will have a
status of QUEUE WAIT. When you reactivate the Queue, Applications Manager will process the tasks based on
their priority settings.

Gantt View Windows

Applications Manager includes a series of Gantt view windows that display useful information such as average vs.
expected runtimes.
Backlog Gantt View
The Backlog Gantt View displays the contents of the Backlog in a real-time Gantt chart format. The chart shows
you whether you are ahead of or behind schedule. You can take actions on tasks or view/edit their task details.
 Applications Manager 9.4.1

History Gantt View

The History Gantt View displays the components of a Process Flow in the History and how they executed. This
view is similar to the Backlog Gantt View.
Graphical Forecast
The Graphical Forecast displays scheduled Jobs and Process Flows in a Gantt chart format. The chart looks very
much like the Backlog Gantt View.
Process Flow Gantt View
The Process Flow Gantt View displays the contents of a Process Flow in a Gantt chart format. The view is similar to
the Backlog Gantt View.

5 Installation Guide
The Installation Guide documents the installation procedures for Applications Manager.
The Installation Guide documents the installation procedures for Applications Manager. It is part of the complete
Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.
 Applications Manager 9.4.1

About This Guide

The Installation Guide documents the installation procedures for Applications Manager. It is part of the complete
Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Applications Manager Installation for UNIX and Windows

The basic Applications Manager install creates an Automation Engine and Local Agent on the host computer.
This chapter covers the installation procedures for both UNIX and Windows.
The Applications Manager installation program installs the following:
• An Applications Manager Automation Engine and its local Agent
• An RMI (Remote Method Invocation) server
Note: If you are installing Applications Manager 9.3.4 on SuSE Linux Enterprise Server 12 or SuSE Linux
Enterprise Server 15, refer to Applications Manager Installation on SuSE Operating System.
Minimum Installation
When you install Applications Manager, you must install at least one Automation Engine and its local Agent on the
host computer. If you wish, you also can install remote Agents on other machines. If the situation warrants, you can
install multiple Automation Engines and local Agents on the same host.
General System Requirements
To install Applications Manager, you will need the following:
• An Applications Manager build for your operating system. For a list of the platforms supported, see the Automic
Compatibility Checker.
• 300 MB disk space on the host system.
• For a small system, 100 megabytes for Oracle database table storage, 50 megabytes for database indexes.
• 12 GB RAM minimum, 16 GB recommended for the Applications Manager host system. If Oracle is running on
the same host, memory requirements will go up accordingly.
• 1 GB RAM minimum for the Applications Manager client.
• A supported Oracle database. For details on supported Oracle versions, see the Automic Compatibility Checker.
• A supported Java run-time environment. For details on supported Java versions, see the Automic Compatibility
Checker.
• An Apache, IIS, or Tomcat Web server installed. For more information, see the information provided by your
selected Web server.
Java Requirement
In order to install an Applications Manager Automation Engine, you must have a supported version of Java
installed. Applications Manager requires a 64-bit Java installed on Windows operating systems.
 Applications Manager 9.4.1

We set jdk.tls.ephemeralDHKeySize to Java version-specific values: 2048 for Java 1.8 and above. If you want
to use 2048 bit certificate keys, both the server (rmiserver) and the client (UI or AgentService) need to be running
Java 1.8 or above. For more information, see your Java documentation.
SSL
The SSL that ships with Applications Manager is the global (exportable) version.
If you want to run with the domestic package, download and unzip the domestic package installation files, then
replace the jar files jcert.jar, jsse.jar, and jnet.jar in the classes directory with the ones from the download. The
classes directory can be found in the following Applications Manager directories:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

HP-UX Systems
If you are installing Applications Manager on an HP-UX system, the HP-UX Runtime Environment for the Java 2
Platform must be installed on your system prior to running the Applications Manager installation. The installation
must be performed by the HP UNIX administrator with root access. For all other platforms, the Java 2 Platform is
installed by the Applications Manager installation script.
Report Storage Requirements
You will need 300 MB of free disk space on the host before proceeding. There must also be enough disk space to
hold all the output (reports and system listings) from Jobs for the retention period specified. If you will be creating
many large reports, you will need more storage space. The Applications Manager administrator should monitor the
file system to ensure there is adequate space available.
Specifying Ports for Firewalls or Other Purposes
If you have a firewall in place, you will want to specify ports for your Applications Manager processes. During the
installation, you will be asked if you have a firewall in place. If you answer yes, you will be able to specify the port
value(s) at that time. If you are not sure which ports to use, consult your network administrator before installing. For
more information on firewall configuration and port assignments, see Overview of Firewall Settings.
Major Steps
The major steps in the installation process are:
• Create the UNIX account or Windows user.
• Create the Oracle database account.
• Run the installation script.
• Start the supporting servers.
• Start the Automation Engine and Agent processes.
• Verify the installation.
Each step is described in detail in this chapter.

Creating the UNIX Account (UNIX Only)

Before installing Applications Manager, create a KORN or BOURNE shell UNIX account.
If you are installing Applications Manager on a UNIX system, the first step in the installation process is to create a
KORN or BOURNE shell UNIX account.
Procedure
To create a UNIX account for Applications Manager:
1. Create a UNIX operating system account on the appropriate host.
 Applications Manager 9.4.1

The recommended shells for the account are either KORN or BOURNE shell. The account name can be any
valid UNIX name. In this manual, we represent the UNIX login name as am. You must be logged into the
Applications Manager UNIX account when you perform the install.
2. Pick or create a directory into which you will install Applications Manager.
It is usual practice to set the home directory for the Applications Manager UNIX account (in .profile) to the
install directory for Applications Manager. In this manual, we typically represent the install directory as /home/
users/am.
3. If you will be installing an Automation Engine and Local Agent, ensure that the environment allows Applications
Manager access to the database it will use for its repository by modifying the .profile file for the Applications
Manager UNIX account.
When the Database Is On a Different Machine Than the Automation Engine
If the database is on a different machine than the Applications Manager Automation Engine, you must set the
TWO_TASK variable. To set TWO_TASK, add the following line to the $AW_HOME/site/sosite file where <Oracle
Sid> is the actual name of your Oracle Sid:

TWO_TASK=<Oracle Sid>; export TWO_TASK

Assigning Rights and Permissions to the Windows User (Windows Only)

The Windows WatchWorx service runs as a Windows service and should run as a specific Windows user: typically
Administrator.
If you are installing Applications Manager on a Windows system, the first step is to assign rights and permissions
to a Windows user. The Windows user will be used to run the Applications Manager Windows WatchWorx service.
WatchWorx monitors all Applications Manager processes and restarts them if they are terminated unexpectedly.
We recommend that the WatchWorx service run as a specific Windows user: typically the Administrator user.
Whichever user the service runs as, that user must have certain advanced user rights and permissions.
Administrator is the default User when installing this service.
Setting Rights and Permissions
The table below notes the rights and permissions required for the Administrator, Applications Manager (custom-
built), and the domain user.

User Rights and Permissions

Administrator (recommended) or Applications Manager • Advanced User Right: log on as a service

• File access permissions to run the programs you
wish to run with this Automation Engine and Local
Agent

Domain/User • Advanced User Right: Act as part of the operating

system
• Advanced User Right: Log on as a service
• File access permissions to run the programs you
wish to run with this Automation Engine and Local
Agent
• Must belong to the domain/administrator group

Remember, you must log out and log in again after changing any user rights. Otherwise, the changes will not
take effect. You should determine which user(s) the Applications Manager services are going to run as before
proceeding with the installation. You will perform the installation as Administrator.
Special Circumstances
Occasionally, certain Windows host configurations do not allow the Applications Manager WatchWorx service to be
installed using a specific user/password. If you are unable to install the Applications Manager service as a specific
user on your Windows host, Broadcom recommends that you do the following:
 Applications Manager 9.4.1

1. Install the Windows Automation Engine/Agent, but leave the Windows User and Password fields blank. By
default Applications Manager installs into the Administrator Account.
2. After you complete the installation, go to the Windows Services and locate the AWW-<Agent name> service.
3. Ensure that the AWW-<Agent name> service's Startup Type option is set to 'Automatic'.
4. Change the Log On As from 'System Account' to 'This Account.' Enter the Windows user account and the
password.
5. Be sure to update the service with an appropriate Windows user name and password.
When the Database Is on a Different Machine than the Automation Engine
If the database is on a different machine than the Applications Manager Automation Engine, you must set the
LOCAL variable. For a new Automation Engine LOCAL should be set in the environment prior to running the
installation. For an existing Automation Engine LOCAL can be set by adding the following line to the %AW_HOME
%\site\sosite.bat file where <Oracle Sid> is the actual name of your Oracle Sid:

LOCAL=<Oracle Sid>

Creating the Database Account

Before installing Applications Manager, create an Oracle database account for the Applications Manager repository.
After creating the UNIX account or Windows user, the next step is to create the database account. For information
on supported Oracle versions, see Automic Compatibility Checker. If you are using Oracle RAC, see Configuring
Applications Manager for Oracle RAC.
Requirements
When you create the database, set the following parameters:
• Shared_pool_size: 20 megabytes minimum
• Database table storage and indexes: 150 megabytes minimum
• Database db_block_size: 8K minimum
• Processes: 100 or greater
Procedure
To create an Oracle account for Applications Manager:
1. Log into the database where you will be creating the Oracle account for Applications Manager and issue the
following command:

grant connect, resource to <am> identified by <password>;

alter user <am> temporary tablespace <tmpspace>;

2. To give the Applications Manager account the privileges required to create tables, views, indexes, procedures,
triggers and sequences, issue the following commands:

alter user <am> default tablespace <tspace>;

In the commands above, replace <am>, <tspace>, and <tmpspace> with appropriate values for your system.
3. To prevent the Applications Manager installation script from prompting for the Oracle sys password, you can
grant the appropriate privilege to a system table ahead of time. Make the following grants from the Oracle sys
account:

grant select on v_$session to <am>;

grant select on v_$lock to <am>;
 Applications Manager 9.4.1

grant select on v_$locked_object to <am>;

grant create view to <am>;
grant create procedure to <am>;
grant create trigger to <am>;
grant create table to <am>;
grant create database link to <am>;
ALTER SYSTEM FLUSH SHARED_POOL;
grant execute on dbms_sql to <am>;
grant execute on dbms_pipe to <am>;
grant execute on dbms_lock to <am>;
grant execute on dbms_output to <am>;
grant alter session to <am>;
grant create synonym to <am>;
grant select on v_$sqltext to <am>;
grant select on v_$sqltext_with_newlines to <am>;

If you have multiple Automation Engines running in the same database, and you try to install a new Automation
Engine in the same database, you may have trouble granting access to dbms_pipe. If you have trouble, try
stopping the other Automation Engines.
Notes for Oracle 12c and Above
When using Oracle 12c database and you have an Oracle Enterprise Edition multi-tenant system or Oracle
Standard Edition single tenant system, you must install Applications Manager into a pluggable database (PDB)
within a container. Your DBA is responsible for creating the pluggable database.
Oracle 12c and above require the following additional grant:

GRANT UNLIMITED TABLESPACE TO <am>;

This is a new requirement as of this release, because the RESOURCE role no longer grants the UNLIMITED
TABLESPACE system privilege by default.
You can change UNLIMITED to 100M or whatever size you feel is appropriate as shown below if space is a
concern.

ALTER USER <am> QUOTA <size> ON <tspace>

All the installation related SYS accounts and passwords are for the PDB (each PDB has its own SYS account just
like a database instance prior to 12c).
(Re)granting Access After Rebuilding the Oracle Database
If you rebuild the Oracle database where Applications Manager is installed any time after an initial Applications
Manager installation, you must (re)grant select execute access to the Oracle system table (SYS.V_$SESSION)
and execute to the procedures dbms_pipe, dbms_lock, and dbms_application_info. To do this, you must run the
sysdba.sql script located in the Applications Managersql directory.
To run the script, log into SQL*Plus using the Applications Manager Login and password, then type 'start sysdba'.
The script will prompt you for the sys Oracle password then grant select access to the SYS.V_$SESSION system
table and the procedures. You can also regrant access by executing the SQL statements shown above in Step 3.
Dropping the Database Pipe
If you must drop an Oracle user, your DBA must first drop the database pipe (otherwise you will have to stop and
restart the database before you can reinstall).
 Applications Manager 9.4.1

System Information Required for the Installation

Applications Manager is a complex product that draws on many elements of your system to work correctly. To
complete the installation successfully, you will need to provide a variety of system information. The information
required is detailed below.
Applications Manager makes every attempt to analyze your system and present default values. These values are
displayed in brackets [ ] next to each question in the UNIX installation, and in the fields in the Windows installation.

Parameter Default Value Description

Install Apache now? Y If you do not already have the

Apache Web server installed, you
can do so during the Applications
Manager install.

Install Automation Engine's Agent? Y You would only answer N in to install

a second RMI server without a Local
Agent for failover as described in
topic Installing a Second RMI Server
for Failover.

Automation Engine name none Before you choose a name:

When choosing a name for the
Applications Manager Automation
Engine and Local Agent, do not
use any of the following reserved
words: ALL, APPWORX, AWCOMM,
AGENTSERVICE, AWAPI, RMI,
RMISERVER, AGENT, and
MASTER.
The name can be up to 30
characters in length.

Automation Engine IP or host name none The IP address.

Applications Manager Oracle login none This is the login name, and
name, and password. password to the Applications
Manager Oracle database account
you set up.

Oracle SQL*Net connect string @ This is the Oracle SQL*Net connect

string (if used) to the Applications
Manager Oracle database. A
connect string is required for Oracle
12c and above, or when installing
Applications Manager into a remote
database. For local database
installations, that do not require a
connect string, accept the default
value of an @ sign when prompted.

Oracle service name none This is the Oracle system identifier

(or PDB service name for Oracle 12c
and above). Check with your DBA
for the correct value.

Full path to SQL*Plus none For Windows installations only.

Points Applications Manager at the
correct database if there are multiple
databases on the same machine.
 Applications Manager 9.4.1

Parameter Default Value Description

Full path to SQL*Loader none For Windows installations only.

Points Applications Manager at the
correct database if there are multiple
databases on the same machine.

Oracle instance IP or host name none This is the IP address or DNS

name of the machine where the
Applications Manager Oracle
database is installed.

Oracle listener port 1521 This is determined by a setting in

Oracle.

Virtual day start time 00:00 This is the time when your daily
processing day starts (usually 00:00
for midnight).

Time zone none The time zone for the Automation

Engine.

Host name and port for SMTP server none Applications Manager can send out
Notifications of events via email. If
you wish to use this feature, you will
need to enter the host name and
port number of your SMTP server.

Email address for Notifications none The email address you want as the
sender for Notifications.

AWCOMM port 2136 The awcomm process provides

a port directory service for the
Applications Manager Automation
Engine and Agents. It is the first
process that comes up when you
start Applications Manager.
Port 2136 is registered with the
Internet Assigned Numbers
Authority, so you should not need to
change it. If you do need to change
the port number, you must edit the
AWCOMM_PORT setting in the
awenv.ini file. For more information
on the awcomm port, see the
Administration Guide.

Automation Engine require its own Yes The Automation Engine must use its
RMI server own RMI server.

RMI registry port 1099 The client uses this port when it
makes initial contact with the RMI
server.

RMI data port 0 Required if there is a firewall in front

of the RMI server. Client data uses
this port in order to pass through the
firewall.
 Applications Manager 9.4.1

Parameter Default Value Description

Sys password none Required to grant necessary

privileges from the SYS account. If
the Applications Manager Oracle
user is on a pluggable DB (PDB),
the field should be entered as:

syspassword@pdbname

Additional Required Information if a Firewall Is Installed on the Automation Engine Machine

The following information is needed if a firewall is installed on the Automation Engine machine. After specifying
ports for the Automation Engine machine, you need to open the ports for inbound and outbound communication.
For more information, see Overview of Firewall Settings.

Parameter Description

RMI Server Port The return port the Agents' AgentService process uses
to communicate to the Automation Engine. This lets
TCP/IP pick random ports each time the processes are
started. This is the typical situation when a firewall is not
in place.
This port is only ever specified in the Automation
Engine's awenv.ini file.

RMI Data Port The listener for the RMI server. Needs to be specified
when a firewall is on the Automation Engine machine.

Client RMI Port Needs to be specified when a firewall is on the

Automation Engine machine.
Applications Manager will use the specified port
number for the RMI server. If 0 is specified in the
ClientRMIPortNumber line, no firewall settings are
configured and the ports are chosen randomly.

Running the Installation Script

After preparing the installation files, the next step is to run the installation script. The installation script installs the
RMI server and the Applications Manager database, Automation Engine, and Local Agent.
In a typical installation, you install one Automation Engine and one Local Agent on a host. Under certain
circumstances, you may want to install two or more Agents on the same host. For a description of how to run
multiple Agents on one host, see Installing Multiple Automation Engines on One Host.
Automation Engine and Local Agent Names
When choosing a name for the Applications Manager Automation Engine and Local Agent, do not use any of
the following names: ALL, AWCOMM, AGENTSERVICE, RMI, RMISERVER, AGENT, MASTER. These are
Applications Manager process names, and if used, can cause problems with start and stop commands issued by
Applications Manager.
Applications Manager Client URL
During the installation, you will be given the URL used to connect to the Applications Manager client server.
Be sure to write down this URL for future reference. It also is available in the aw_install.log file located in the
Applications Managerinstall directory. Search for the text 'URL for future reference'.
Running the UNIX Installation Script
 Applications Manager 9.4.1

In UNIX, when you run the installation script, Applications Manager displays the default information for prompts in
brackets [ ]. You can accept the default by pressing the Enter key at the prompt, or type in a response and press
the Enter key.
To run the installation script:
1. Log into the Applications Manager UNIX account.
If necessary, change to the directory where you want Applications Manager installed.
You must be logged into the Applications Manager UNIX account or be logged in as the appropriate Windows
user, and be in the Applications Manager directory for the installation procedure to work correctly. Moving the
files after the installation is complete requires some effort. It is best to install into the correct directory the first
time.
In UNIX, if you transferred files to a staging directory, verify that all the Applications Manager files are owned
by the Applications Manager UNIX login and group. If they are not, the installation will fail. Use the chown and
chgrp commands to modify the ownership if necessary.
2. From the directory in which you want Applications Manager installed, run CDINST.SH on the host.
Be sure to set permissions for the CDINST.SH file.
3. Follow the on-screen prompts using the information from topic System Information Required for the Installation.
4. When presented with the menu of installation options, choose the following option and continue.

01 Initial install/upgrade from prior version

Running the Windows Installation Script

To run the Windows installation script, run cdinstall.bat on the installation disk and follow the on-screen prompt
using the information from topic System Information Required for the Installation.
It is recommended to install in a directory without spaces. Depending on your Windows system configuration issues
for pathing, it can cause issues if you install in a directory with spaces.
Next Step
You have run the installation script. If you entered an IP address for the host machine, the next step is to start the
Applications Manager processes. See the appropriate topic for your platform:
Starting and Stopping the Applications Manager Processes in UNIX
Starting and Stopping the Applications Manager Processes in Windows

Starting and Stopping the Applications Manager Processes in UNIX

The Applications Manager processes must be running for communication to occur between the Applications
Manager Automation Engine, Agents, and Applications Manager clients. To start the processes, issue the startso
command from the Applications Manager UNIX command line.
The AgentService process runs on all Agents. Normally additional process called RmiServer and awcomm are
run on the Automation Engine machine. To ensure secure communications between the Automation Engine and
the various processes, all messages are encrypted.
To see the status of the Applications Manager process, you can issue an awexe node command.
Establishing the Proper Environment
Before starting or stopping the processes, you must establish the proper environment by logging out of UNIX and
logging back in, or issuing the following command from the home directory of the Applications Manager UNIX user:

. .profile
 Applications Manager 9.4.1

The following lines have been added to $HOME/.profile during the installation process:

AW_HOME=/home/<am>;export AW_HOME
. /home/<am>/site/sosite

Starting and Stopping Processes with startso and stopso

The startso and stopso commands are used to start and stop Applications Manager processes. You can issue
them by themselves or with parameters. It is generally recommended that you start and stop processes with
startso all and stopso all commands to start and stop all processes. If monitoring processes with WatchWorx,
use the startso watchworx and stopso watchworx commands. Additional parameters that can be used with the
startso and stopso commands are described in the Administration Guide.
Starting Processes, but Not Backlog Tasks
If you are starting Applications Manager as part of a boot sequence, you may want to start Applications Manager
processes, but not allow the Automation Engine to execute tasks until you have had a chance to view the contents
of the Backlog. You can set this up with the following series of commands.

startso
stopso master

In this series of commands, the startso command starts the awcomm, AgentService, and RmiServer processes
on the Automation Engine.
The stopso master command puts the Automation Engine into a Stopped status, but doesn't stop any processes,
because those elements are performed on threads of the RmiServer process.
Accommodating More than One awcomm Process
If there will be more than one awcomm process running on a host, you must set a different port number for each
process. For information on sharing processes between multiple Agents on the same host, see Installing Multiple
Automation Engines on One Host.

Starting and Stopping the Applications Manager Processes in Windows

Before you can open the Applications Manager client and process tasks, you must start the Applications Manager
processes. You can start the processes from the Start menu or the command line.
The startso and stopso commands are used to start and stop Applications Manager processes in UNIX and
Windows. In Windows, you can also start and stop processes from the Windows Start menu. You can issue the
startso and stopso commands by themselves or with parameters. Before starting or stopping processes, you must
set the environment. You can issue these commands on Automation Engine or Agent machines.
To see the status of the Applications Manager process, you can issue an awexe node command.
Starting and Stopping the Applications Manager Processes from the Start Menu
To start the processes from the Start menu: open the Start menu on the Windows desktop, choose Programs,
point to Applications Manager, and click Start Applications Manager Processes. This command also starts the RMI
server which contains the Applications Manager Automation Engine.
To stop the processes from the Start menu: open the Start menu on the Windows desktop, choose Programs, point
to Applications Manager, and click Stop Applications Manager Processes.
Starting and Stopping Individual Processes from the Start Menu
To start or stop an individual process from the Start menu: open the Start menu on the Windows desktop, choose
Programs, point to Applications Manager, and click the appropriate command for the Automation Engine or Agent.
Establishing the Proper Environment
Before issuing commands from the DOS prompt, establish the appropriate environment for Applications Manager
by executing the %AW_HOME%\site\sosite.bat file.
 Applications Manager 9.4.1

To start the processes from the DOS prompt, issue the startso command. The startso command will start all
applicable Applications Manager processes for the current environment. If an Automation Engine and Local Agent
are installed, startso will start both Automation Engine and Agent processes. If only a Remote Agent is installed,
startso will start only the Agent process.
To stop the processes from the DOS prompt, issue the stopso command. The stopso command will stop all
applicable Applications Manager processes for the current environment. If an Automation Engine and Local Agent
are installed, stopso will stop both Automation Engine and Agent processes. If only a Remote Agent is installed,
stopso will stop only the Agent process.
Starting and Stopping Processes with startso and stopso
The startso and stopso commands are used to start and stop Applications Manager processes. You can issue
them by themselves or with parameters. It is generally recommended that you start and stop processes with the
basic startso and stopso commands, or if monitoring processes with WatchWorx, with the startso watchworx
and stopso watchworx commands. Additional parameters that can be used with the startso and stopso
commands are described in the Administration Guide.
Starting Processes, but not Backlog Tasks
If you are starting Applications Manager as part of a boot sequence, you may want to start Applications Manager
processes, but not allow the Automation Engine to execute tasks until you have had a chance to view the contents
of the Backlog. You can set this up with the following series of commands.

startso
stopso master

In this series of commands, the startso command starts the awcomm, AgentService, and RmiServer processes
on the Automation Engine.
The stopso master command doesn't stop any actual processes, because those elements are performed on
threads of the RmiServer process.

Opening the Applications Manager Client and Logging In

You must download the Applications Manager client from the URL set during the installation your Applications
Manager sent you . Before logging in the first time, you need to configure the client for the Automation Engine(s)
you will be logging into. Once configured, you open an executable .jar file. To log into the client, you must enter
your User name, password, and select an Automation Engine.
Downloading and Opening the Applications Manager Client
To download and open the Applications Manager client:
1. Open your browser and enter the URL set during the installation your Applications Manager sent you. The
screen shown below is displayed.
The default format for the URL is http://<Automation Engine IP address>:<Web Server port number>/
<Automation Engine name>/Intro.html.
For example, if the Automation Engine IP address is 200.2.2.123, the port number is 8080, and the
Automation Engine name is PROD1, the URL would look like the following:

http://200.2.2.123:8080/PROD1/Intro.html
 Applications Manager 9.4.1

The Applications Manager client requires a supported version of the Java Runtime Environment (JRE). For a
list of compatible Java versions, click the Compatibility Matrix link.
2. From this page, click the Download the Applications Manager Client link.
This downloads the Client.zip file.
3. Create a directory on your local PC for the client, for example, C:\AM_Client.
4. Move the Client.zip file to the directory you created and unzip the contents in that location.
5. Copy connections.properties.template to connections.properties.
6. Edit connections.properties. Replace {MASTER} with the name of your Applications Manager
Automation Engine and {URL} with the URL to your Applications Manager Automation Engine, such as,
http://127.0.0.1:8080/AMPROD.
For example, you might replace...

{MASTER}={URL}

With...

AMPROD=http://127.0.0.1:8080/AMPROD

To add connection information for additional clients, simply add additional lines in the same format.
7. Copy client.properties.template to client.properties.
8. Optionally, edit client.properties to set client properties.
Text from a sample client.properties file is shown below.

#localOptions=true
#debug=true
#logDir=log
#JAVA_HOME=C:/Program Files/Java/jdk-11
 Applications Manager 9.4.1

runOptions=-Xmx256m

The client.properties file includes the following settings:

• localOptions: When set to true, Applications Manager uses a local Options.properties file on your PC.
The local Options.properties file will be in a sub-directory for the client with the master's name. The local
Options.properties file will be download once. The advantage of using a local Options.properties file is
that you can specify settings for yourself without affecting other users. When set to false, commented out
(default), or otherwise not set to true, the Options.properties file on the Automation Engine machine is
used.
• debug: Allows you to turn on client debug by entering debug=true. When client debug is set, debug
information is written to the files in the log sub-directory or a different sub-directory is one is specified under
logDir.
To turn debug off, comment out debug=true in the client.properties file like the following.

#debug=true

It is also possible to set client debug from the About Applications Manager window once you are logged
into the client. However, it is advantageous to set it here, so that debug is on for the client start-up.
• logDir: Allows you to override the name of the sub-directory where client log files are written.
The client log sub-directory includes the following files:
• client.log: Includes all client standard and debug logging up until you click OK on the Logon window.
• <master or connection name>_client.log: Includes all client standard and debug logging for your
client session.
• JAVA_HOME: Allows you to use a different Java than your PC's default Java.
You must use either forward slashes (recommenced) or double backslashes in the path. This is the
standard for Java properties files.
To see your PC's default Java, open a command prompt and type java -version.
• runOptions: Used to increase the memory for your client. Don't make any changes to this setting unless
directed to by Applications Manager support.
• TheuserLanguageFiles: This setting is hidden in the client.properties file and in the documentation by
default. It allows you to specify a master name to use language translations on. When a master is specified,
there will be a drop-down with the languages, which are specified in the Options.properties file for the
master. We believe no one uses this desupported feature anymore.
9. Use RunClient.jar to start the Applications Manager client.
Applications Manager displays the Login window shown below.

Optionally, you may create a shortcut of RunClient.jar and place the shortcut on your desktop.
If the Logon window does not come up, open command window, navigate to the client directory, and enter
java -jar RunClient.jar to see the output. This information will help you or Applications Manager support
troubleshoot the problem.
When starting the local client by double clicking on RunClient.jar (or a shortcut to it) in version 9.3.1 or above,
if it fails to start the error will now be in the startClient.log file.
10. On the Logon window, specify your User, password, automation engine.
User names are not case sensitive, but passwords are.
If you do not know your User name and password, check with your Applications Manager administrator.
11. If the Language field is available, select your language.
Specifying languages for the client is a desupported feature. The Language field is only available in
Applications Manager systems where languages were translated in a previous version.
12. On the Logon window, specify the following:
• The default user name SQLOPER.
 Applications Manager 9.4.1

• The default password is s0pass, where "0" is zero.

13. To have Applications Manager remember your User name and Automation Engine, select the Remember
logon button.
14. To accept the entered information and log on to Applications Manager, click OK.
If you have a large number of output files or tasks in the Backlog, Applications Manager will display a message
alerting you that the display has been truncated.
When you log out of Applications Manager, the following settings are remembered the next time you log back
in:
• The size and position of Explorer and Backlog Gantt View windows.
• The size and position of the main Applications Manager client window.
• The content pane of the Explorer window (if open).
• Whether a saved Backlog/History Filter was selected.
Upgrading the Client
To upgrade to a new version of the client:
1. Download the new version of the client Client.zip from the URL
set during the installation
your Applications Manager sent you
.
2. Delete everything except the connections.properties and client.properties files from your client directory.
3. Put the files from the new version of the Client.zip file into your client directory.
Receiving RmiServer Error Broadcasts
If the Receive RmiServer Error Broadcasts User Option is assigned to your User, the RmiServer Errors window
might pop up with one or more errors when you log in.

When the Receive RmiServer Error Broadcasts User Option is assigned to a User, any RMI errors will be
displayed in a pop-up window as they occur. Additionally, if any RMI errors occurred since the last time the RMI
server was started, the last ten errors will be displayed in a pop-up window each time the User logs on.
If you have the DBA User Group, you can clear the RMI errors without stopping the RMI server by selecting Clear
RMI Errors from the View menu on the Applications Manager Desktop.
Re-Logging on to Applications Manager
There may be times when you want to log on to Applications Manager under a different user name or connect to
a different Automation Engine. To change your logon from the desktop, go to the File menu and select Re-Login.
You will have to re-enter your password when you re-log in, unless the Disable clearing of login passwords on
re-login Automation Engine option is checked.
Changing Your Password
You can change your password at any time. Your Applications Manager administrator can also set your password
to expire after a certain period of time.
To change your Applications Manager password go to the Options menu on the Applications Manager desktop and
click Change Password.
Accessing the Client Through a Firewall
If you will be accessing the Applications Manager client through a corporate firewall, you must open the appropriate
ports, and specify those ports in the Options.properties file on the host machine.
For details, see Configuring the Applications Manager Client.
For details, see the Installation Guide.

Verifying the Installation

After completing the installation, and starting the Applications Manager Automation Engine and Agent processes/
services, you should verify that Applications Manager is installed correctly and ready to start processing tasks. A
good test is to run a Job.
Procedure
To begin the verification:
 Applications Manager 9.4.1

1. Launch the Applications Manager client and log in as User SQLOPER.

2. From the Activities menu, select Requests.
Applications Manager displays the Requests window shown below.

3. Select TEST_JOB from the list and click Request. To quickly find TEST_JOB, type the letter 't' in the Search
field.
The Submit window appears as shown below. TEST_JOB requires one prompt value—a number of seconds to
sleep. It has a default value of 5 (seconds) which will work for now.
4. To run TEST_JOB, click Submit & Close.
 Applications Manager 9.4.1

5. To monitor the task, open the Activities menu and select Explorer.
The TEST_JOB should complete successfully with a status of FINISHED. The TEST_JOB will then leave the
Backlog and a record will be displayed in History.

Verification Complete
If TEST_JOB finished, then Applications Manager has been installed correctly. Verification is complete. If you have
special considerations in your environment, you may want to look in chapter Applications Manager Installation—
Advanced Topics for additional information.
If TEST_JOB did not run, or did not complete with a status of FINISHED, contact Broadcom Support.
 Applications Manager 9.4.1

Applications Manager Installation—Advanced Topics

This chapter covers advanced installation topics for both UNIX and Windows. You may find these topics useful for
configuring Applications Manager to meet your specific system requirements.
Copying and Moving Applications Manager Instances
The Administration Guide gives instructions for the scenarios that customers deal with most frequently when
copying and moving Applications Manager instances. It includes topics on the following:
• Copying or moving a Applications Manager Automation Engine and database to the same machine or a different
machine
• Moving a Applications Manager Automation Engine to another machine
• Moving an Applications Manager database to another machine

Configuring the Applications Manager Client

After running the installation script, the next step is to optionally configure the Applications Manager client.
The Applications Manager client brings operations functionality to a Web browser interface. When you install
Applications Manager on a server, you make the Applications Manager client available to all users via a URL
address designated by the Applications Manager administrator. The browser interface simplifies distribution and
maintenance by eliminating the need to install software on each user's machine.
After installing the Applications Manager client, you can customize settings for the client in the Options.properties
properties file.
The location for the Options.properties file is:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

Options.properties
The Options.properties configuration file controls how the Applications Manager clients interact with the
Automation Engine, and other features such as the image used for the splash screen. The file includes host,
database, and login information. The file is self-documenting. However, if you have questions about altering the file,
contact Braodcom Support.
Accessing the Client through a Firewall
If you will be accessing the Applications Manager client through a corporate firewall, you must open the appropriate
ports, and modify the Options.properties file on the host machine. For details, see Overview of Firewall Settings.

Function of the Operating System User

Applications Managerautomatically creates an operating system user for validating backend processes. DO NOT
delete this User.
As part of the installation process, Applications Manager creates an operating system user based on the
information you provided. Applications Manager uses the operating system user to verify backend processes. DO
NOT delete this User.
If you view the Users Selector window, you will see the OS user listed. In the image below, the OS user is QA4.
 Applications Manager 9.4.1

When Applications Manager creates the OS user, it does not assign it a password, because you should not have to
log into Applications Manager as the OS user.
If you must log into Applications Manager as the OS user, go to the Users window, select the OS user, and create
a password as shown below.
 Applications Manager 9.4.1

Awexe Range for the OS User

The numbers entered in the Awexe range field correlate to a range of options listed in the awserver_sql.dat file
located in the data directory. Users will have access to the functions assigned to them from the command line. The
OS user should have 1000-9999 set in this field.

Configuring Applications Manager for Oracle RAC

This topic describes how to configure Applications Manager to work with Oracle RAC. This method has been tested
with an Oracle RAC running on 10.0.3.
If you will be using Applications Manager with Oracle RAC, you must have the 6.0.7 Oracle RAC patch, or be
running Oracle 6.0.7 or higher.
There are three main steps for configuring Oracle RAC:
1. Configure the Applications Manager processes to use SQL*Net.
2. Configure the tnsnames.ora file for the Applications Manager C stack.
3. Configure the Applications Manager RMI Server.
Before Applying the Patch
Before applying the 6.0.7 Oracle RAC patch, you should back up the following files:

bin/CLASSPATH
/web/classes/AppWorxLang.jar
 Applications Manager 9.4.1

/web/classes/UserWorx.jar

Configuring the Applications Manager Processes to Use SQL*Net

The Applications Manager C AgentService processes connect to the Oracle database on the Applications
Manager Automation Engine machine and handle all database transactions issued by Agents. In an Oracle RAC
environment, these processes need to be configured to run through SQL*Net. This can be accomplished by doing
one of the following:
• Enter the Oracle RAC database connect string when prompted for the Oracle login by the Applications Manager
installation program.
• Before running the Applications Manager installation program, set the variable TWO_TASK to the Oracle RAC
connect string in the environment, and after the installation is complete, add the TWO_TASK variable to the
sosite file. The sosite file is located in the site directory in the Applications Manager home directory.
Configuring the tnsnames.ora File for the Applications Manager C Stack
The TNS Name definition for the Oracle RAC should have all the parameters set for the database instances to
which Applications Manager can connect. An example of a tnsnames.ora file is shown below where the TNS name
for Oracle RAC is ORCLFAILOVER:

ORCLFAILOVER =
(DESCRIPTION_LIST =
(FAILOVER = TRUE)
(LOAD_BALANCE = FALSE)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux1)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.am.com)
(INSTANCE_NAME = awrac1) ) )
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux2)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.am.com)
(INSTANCE_NAME = awrac2) ) ) )

Configuring the RMI Server

The RMI server is the process that serves information to the Java client and runs the Applications Manager
Automation Engine process. It connects to Oracle instances through JDBC over SQL*Net.
To configure this for Oracle RAC, you need to add an entry into the Options.properties file. The location for the
Options.properties file is:
UNIX:

$AW_HOME/web/classes
 Applications Manager 9.4.1

Windows:

%AW_HOME%\web\classes

The entry is "OracleRAC" and it is nearly identical in content to the tnsnames.ora entry. It should contain all the
information for the database instances that Applications Manager can connect to. Here is an example of the same
connection above as it would appear in Options.properties:

OracleRAC= (DESCRIPTION = \
(ADDRESS = (PROTOCOL = TCP) \
(HOST = vip-linux1) \
(PORT = 1521)) \
(ADDRESS = (PROTOCOL = TCP) \
(HOST = vip-linux2) \
(PORT = 1521)) \
(LOAD_BALANCE = FALSE)\
(FAILOVER = TRUE) \
(CONNECT_DATA = (SERVER = DEDICATED)\
(SERVICE_NAME = awrac.am.com) ) )

Note that the slashes at the end of each line are required so the entry is interpreted by the RMI Server as one
continuous line.
Also, setting the OracleRAC line will override the DB_IP, DB_PORT, and DB_SID in the awenv.ini file.
Notes on Behavior
At this time we recommend using Applications Manager only in a FAILOVER configuration for Oracle RAC. Load
balancing configuration should be avoided.
Our processes 'sleep' and 'wake up' on Oracle DMBS pipes. Pipes are instance-specific, so if Applications
Manager processes are balanced across instances, then wake-ups issued by one process may not reach the
target process. The Automation Engine and Agent sleep times can be reduced, but this is not ideal because of
performance issues.
Expected Failover Behavior
When a failover happens (one instance goes down), the Applications Manager processes should connect to the
new Oracle instance fairly quickly. Because some of the database processes might have been issuing a database
transaction at the time of the failure, it is possible to lose a transaction or two during this switch. This could result in
a task going into a DIED status or a node going into BUSY status.
We have not seen this in our testing, but it is a possibility. Our processes will retry most statements if they get a
failure on the first try.
If these types of errors do happen, it is expected behavior and not critical. For died tasks, check the task output to
see that the process was finished (it should have been). Agents that go into a BUSY status should go back to a
RUNNING status at the end of the sleep cycle after the Applications Manager stack has reconnected.

Installing Multiple Automation Engines on One Host

Broadcom does not recommend running multiple Applications Manager Automation Engines on the same host. If
you must resort to this configuration, you must set a number of parameters.
If you want to install multiple Applications Manager Automation Engines on the same machine, run the install script
once for each Automation Engine. The Automation Engines can use the same awcomm process, but they should
use separate Applications Manager RMI servers. The advantage to separate RMI servers is that you can shut
down one instance and its RMI server without affecting the other instances. For example, you could shut down a
development instance without impacting a production instance.
Each Automation Engine should be assigned different ports for the following:
 Applications Manager 9.4.1

• Web server
• RMI registry
• RMI data port
When installing multiple Automation Engines on one host, you will need to pay careful attention to your
environment. For example, on UNIX you need to consider how you call sosite. When sosite is called in the UNIX
user's .profile script, that means the wrong sosite might be invoked. Different situations call for different solutions,
but consider running Automation Engines under different OS users or invoking the sosite file manually, not in
.profile.
The awcomm Process
The awcomm process provides a port directory service for the Automation Engine machine. You need only one
awcomm process, even if you are running different Applications Manager instances and versions. This is possible
because you can shut down an Applications Manager instance without shutting down the awcomm process.
The default setting for the awcomm port is 2136. To change the awcomm port, edit the AWCOMM_PORT line in
the [default] section of the awenv.ini file in the site directory.
RMI Registry Port
The default setting for the RMIRegistryPortNumber is 1099. The file you need to edit to change the port is listed
below.
The Options.properties file in the following directory:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

RMIDataPortNumber Port
The default setting for the RMIDataPortNumber is 0. The actual port used will be a randomly chosen open port.
You can keep this at 0 for all your Automation Engines, if you want (as long as you don't have a firewall). The file
you need to edit to change the port is listed below.
The Options.properties file in the following directory:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

Configuration for Machines with Multiple IP Addresses

Applications Manager needs to be configured to work on networks with machines that have multiple IP addresses.
This topic covers the IP addresses used by each process, how Applications Manager determines what they are,
and how to set them manually.
Process IP Overview
 Applications Manager 9.4.1

RMI server process: The RMI server process is a Java process that runs on the Automation Engine machine. The
RMI server IP address is the only IP that is specifically set during the install. This setting, RMIHostID, is specified in
the Options.properties file.
The location for the Options.properties file is:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

The Automation Engine process runs as a thread under the Java process that also runs the RMI server. It will use
the same IP address that the RMI server uses, which is the RMIHostID setting.
Agent service process: The Agent service process is a Java process that runs on every Agent. The Agent service
by default uses the IP address returned by the gethostbyname function. You can see what this is by executing
the gethost program in the c directory on the Agent. This will be the return IP address that the Automation Engine
machine will use to communicate back to on the Agent. It will also be used for validation and should match the IP
address that is set in the client's Agent manager when creating the entry for the Remote Agent.
If gethost does not return the correct IP, it needs to be set manually. To set this manually to a different IP address
you can set the variable AgentIP in the awenv.ini file.
awapi process: Each Agent has an awapi process that connects to the Local Agent service process. In order for it
to connect successfully, the awapi process must be validated by the Agent server process. To do this, it compares
the Applications Manager OS user and IP address that the awapi process starts under to the OS user and IP
address that were set when creating the Agent object.
The awapi process will also use the IP address returned by the gethostbyname function, which you can determine
by executing the gethost program in the c directory on the Agent. This cannot be changed. However, if this does
not match what is in the Agent definition, you can create a file named remote_rmi.dat in the data directory on the
Agent to allow the Agent service to validate the awapi. This file should contain one line with the values:

<Agent name> <agent IP address in its definition> <Applications Manager user>

So, for example, it would look like this if the IP address in the Agent definition is set to '200.1.1.1':

QATEST 200.1.1.1 qauser

Sample Configuration
Here is an example of the settings for a network with multiple IP addresses:
Automation engine machine:
• Automation engine name: MSTR_TEST
• IP addresses: 200.1.1.1, 200.1.1.2
• IP address for clients to access: 200.1.1.1
• IP address used for communicating to Agents and that Agents will communicate to: 200.1.1.2
• IP Address returned by gethost: 200.1.1.2
Remote Agent machine:
• Agent name: RA_TEST
 Applications Manager 9.4.1

• User: awuser
• IP addresses: 200.1.1.3, 200.1.1.4
• IP address set in the Agent definition: 200.1.1.3
• IP address returned by gethost: 127.0.0.1
Automation engine settings:
The Options.properties file will have the following setting:

RMIHostID=200.1.1.1

The awenv.ini file will have the following additional setting:

[default]
RMIServerIP=200.1.1.2

Remote Agent settings:

The awenv.ini file will have the following additional setting:

[default]
AgentIP=200.1.1.3

Automation Engine, Agent, and Client Firewall Connections

When firewalls are in place, ports must be specified in the awenv.ini files for the Automation Engine and all Remote
Agents. RMI server ports must also be specified in the Options.properties file. The necessary ports must also be
open in the firewalls.
Port settings are described for Automation Engine/Agent communications and RMI server client communications. A
diagram for both follows.
Specifying Automation Engine/Agent Ports
There are three critical ports for communication between the Automation Engine and Agent.
1. MasterServerPort: Set in the Automation Engine's awenv.ini file and used by the RMI server Java process.
2. AgentClientPort: Set in each Remote Agent's awenv.ini file and in the Automation Engine's awenv.ini file for
the Local Agent. Used by the Agent service process on each Remote Agent, and by the Agent service process
for the Local Agent on the Automation Engine.
3. AWCOMM_PORT: Set in the Automation Engine and Remote Agents' awenv.ini file. The awcomm
process provides a port directory service for the Applications Manager Automation Engine and Agents. The
AWCOMM_PORT number must be the same on the RMI server/Automation Engine and all Remote Agents.
Automation Engine/Agent Ports That Must Be Open in Firewalls
On the Automation Engine machine the following ports need to be opened:
• AWCOMM_PORT
• MasterServerPort
On the Remote Agent machine the following ports need to be opened:
• AWCOMM_PORT (outbound)
• AgentClientPort (inbound)
Specifying Client/RMI Server Ports
The RMIRegistryPortNumber and RMIDataPortNumber settings are specified in the Options.properties file on
the Automation Engine machine. The location for the Options.properties file is:
 Applications Manager 9.4.1

UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

Client/RMI Server Ports That Must Be Open in Firewalls

Ports for RMIRegistryPortNumber and RMIDataPortNumber need to be opened on the Automation Engine and
client machines.
Process Communication Diagram
The diagram below shows the settings used for communications between Applications Manager processes on an
Automation Engine/Local Agent, Remote Agent, and Applications Manager client.

Connections with Continuous Activity

The following connections have continuous activity:
• AgentClientPort <-> MasterServerPort: Activity will occur every 60 seconds with the default sleep time of 60.
This can be increased or decreased.
• AgentClientPort <-> AWCOMM_PORT: Activity will occur when the Agent first connects to the Automation
Engine machine, then this socket is closed.
 Applications Manager 9.4.1

• RmiRegistryPortNumber <-> Applications Manager client: Activity will occur when the client first logs in,
then this connection is closed. Activity will occur on the entry of data and during the refresh process. This
connection is dependent on auto-refresh being on if no interaction is taking place.

Overview of Firewall Settings

The ports to open for inbound and outbound firewalls for the RMI server/Automation Engine, Remote Agents, and
client are listed below.
You specify the ports Applications Manager processes use to communicate between machines when running the
install script for your Automation Engine and Remote Agents. To update these settings, simply re-run the install
scripts. Once your ports are specified you will need to open them for inbound and outbound communication in your
firewall software.
Ports to Open on the Automation Engine/RMI Server for Inbound Communications
Open the following ports for inbound communications on the Automation Engine/RMI server:
• Awcomm port: Set in the Automation Engine's awenv.ini file during the Automation Engine install.
• Automation engine server port: Set in the Automation Engine's awenv.ini file during the Automation Engine
install.
• RMI register port: Set in the Automation Engine's Options.properties file during the Automation Engine install.
Ports to Open on the Automation Engine/RMI Server for Outbound Communications
Open the following ports to for outbound communications on the Automation Engine/RMI server:
• Awcomm port: Set in the Automation Engine's awenv.ini file during the Automation Engine install.
• Remote Agents' client ports: Set in each Remote Agent's awenv.ini file during its install. If you specify different
Agent client ports for your Remote Agents, you will need to open each of those ports.
• RMI client port: Set in the Automation Engine's Options.properties file during the Automation Engine install.
• RMI data port: Set in the Automation Engine's Options.properties file during the Automation Engine install.
• Web server port: For more information, see your Web server documentation.
Port to Open on the Remote Agents for Inbound Communications
The Remote Agents' client ports must be open for inbound communications on the Remote Agents. Set in each
Remote Agent's awenv.ini file during its install.
Ports to Open on the Remote Agents for Outbound Communications
Open the following ports for outbound communications on the Remote Agents:
• Awcomm port: Set in the Automation Engine's awenv.ini file during the Automation Engine install.
• Automation engine server port: Set in the Automation Engine's awenv.ini file during the Automation Engine
install.
Ports to Open on the Clients for Inbound Communications
Open the following ports for inbound communications on the Applications Manager clients:
• RMI client port: Set in the Automation Engine's Options.properties file during the Automation Engine install.
• Web server port: For more information, see your Web server documentation.
Ports to Open on the Clients for Outbound Communications
Open the following ports for outbound communications on the Applications Manager clients:
• RMI registry port: Set in the Automation Engine's Options.properties file during the Automation Engine install.
• RMI data port: Set in the Automation Engine's Options.properties file during the Automation Engine install.
Applications Manager clients inside the corporate environment bypass the firewall. They communicate directly with
the host using the host's name.

Configuring Agents to Validate Multiple Automation Engine Configurations

You can configure a Remote Agent to recognize more than one IP address for the Automation Engine with the
MASTER_IP_ADDRESS and ALT_MASTER_IP_ADDRESS lines in the Remote Agent's awenv.ini file.
There may be times when you need to configure a Remote Agent to recognize more than one IP address for the
Automation Engine. For example:
• You are working with a clustered machine.
 Applications Manager 9.4.1

• The Applications Manager Automation Engine runs on an IP address, but is recognized as having another IP
address.
• For failover, you may need to list the IP addresses of multiple Automation Engines, Agents, and/or clusters that
are used by a Remote Agent.
When the Automation Engine communicates with the Remote Agent, the incoming IP address is validated. To
validate the Automation Engine's IP address, the Remote Agent checks its awenv.ini file in the site directory for
the IP address listed on the MASTER_IP_ADDRESS line. If that IP address does not validate, the Agent checks
the IP address listed on the ALT_MASTER_IP_ADDRESS line (if present). Sample code from the awenv.ini is
shown below:

MASTER_IP_ADDRESS=400.3.2.45
ALT_MASTER_IP_ADDRESS=444.3.2.66

Using Custom SSL Certificates for Connection Authentication

An SSL certificate is now necessary to connect Automation Engine with Remote Agent and Clients. Using your own
certificate prevents unauthorized connections between the connection endpoints.
The SSL certificate provided can be a self-signed certificate or issued by a CA (Certificate Authority).
To configure the SSL certificate on your server.
1. Create a user_keystore file.
• With self-signed certificate:

keytool -keystore user_keystore -keyalg RSA -genkey -alias "AM" -storetype JKS -storepass
<password>

The following is a sample location where the file gets generated: C:\Program Files\AdoptOpenJDK
\jdk-11.0.6.10-hotspot\bin
• With CA issued certificate:
A .CER file can be imported to a keystore using the following command:

keytool -importcert -file certificate.cer -keystore user_keystore -alias "AM" -storetype JKS -
storepass <password> -trustcacerts

2. Create a user_keystore_config file.

To encrypt the password, go to the AW_HOME/web/classes directory, ensure that AW variables are exported
and run the following command:

java -DAW_HOME=${AW_HOME} -cp AppWorx.jar;uc4-ra.jar

com.appworx.util.EncryptKeystoreFile <password>

The following is a sample location where the file gets generated: AW_HOME\data
CA Issued Certificate
From 9.3.5 and above, if the Certificate is CA Issued Certificate, copy the generated user_keystore and
user_keystore_config files to the <install-dir>\data directory present on the Automation Engine
machine.
 Applications Manager 9.4.1

If the certificate is self-signed, user_keystore and user_keystore_config files need to copied to Remote
Agents and Client machines.
On each user's client machine, create a C:\Users\<user name>\AppWorx\<master name> folder for each
master in the connections.properties file where <user name> is the actual user's name and <master
name> is the name of the master. Then place copies of the user_keystore and user_keystore_config
files for each master in the sub-directory for that master. This allows for different keystores to be used on each
master.On each Remote Agent machine, the user_keystore and user_keystore_config files need to be
copied to data directory of the Remote Agent installation directory.

Uninstalling Applications Manager

The following instructions can be used to uninstall an Applications Manager UNIX Automation Engine and Local
Agent, or a Remote Agent. If you are uninstalling a Remote Agent do not drop the Oracle user.
To uninstall Applications Manager, you must:
• Stop all Applications Manager processes.
• Remove the AW_HOME directory and all the files it contains.
• Drop the Oracle user with the cascade option.
Stopping All Applications Manager Processes
To stop the Applications Manager backend stack and RMI server, you will first need to set the correct environment
by going to the Applications Managersite directory and issuing the following command:
UNIX:

. sosite

Windows:

sosite

Next, issue the following commands:

stopso all
stopso awcomm

Removing the AW_HOME Directory in UNIX

When you installed Applications Manager, you designated a home directory. You must remove this directory and all
sub directories and files.
To remove the directory:
1. Navigate to the parent directory of the Applications Manager home directory.
2. Issue the following command:

rm -r $AW_HOME

Where $AW_HOME is the Applications Manager home directory.

Removing the WatchWorx Service in Windows
 Applications Manager 9.4.1

The WatchWorx service monitors Applications Manager processes and restarts them if they stop. You should
remove the service before you remove the Applications Manager directory. To remove the WatchWorx service on a
Windows system, run the Applications Manager installation script awinstall and choose option 6.
Removing the AW_HOME Directory in Windows
When you installed Applications Manager, you designated a home directory. You must remove this directory and all
sub directories and files.
To remove the directory:
1. Using Windows Explorer, navigate to the parent directory of the Applications Manager home directory.
2. Delete the directory.
Dropping the Oracle User
When you installed Applications Manager, you created an Applications Manager Oracle user, usually 'am' or
something similar. You must drop the user and all tables associated with the user.
If it becomes necessary to drop an Applications Manager Oracle user, you must first run the following SQL*Plus
script logged in as that particular Oracle user (otherwise you will have to stop and restart the database before you
can reinstall):

declare ret number;

begin
dbms_pipe.purge('<user name>PIPE_MASTER');
ret:=dbms_pipe.remove_pipe('<user name>pipe_master1');
end;
/

Where <user name> is the name of the Oracle user and is not SYS or SYSTEM.
To drop the user, log into Oracle as SYS and issue the following command:

drop user <user name> cascade;

Installing a Second RMI Server for Failover

You install an RMI server for failover by running the installation script as you would when installing an Automation
Engine. You can share the Web server with the original RMI server, or install a separate one. After installing the
RMI server, you need to add it to the RmiServer Config window in the Applications Manager client.
To install a Second RMI Server for Failover:
1. Install an RMI server for failover by running the installation script as you would when installing an Automation
Engine.
• For UNIX: Follow the on-screen prompts and be sure to enter the same values for this RMI server as you did
for the original Automation Engine installation.

For the prompt: Do the following:

Install Automation Engine's Agent [Y] Enter N.
Install only a Rmi Server (exit if No ) [Y] Hit the Enter key to accept the default value of Y.
 Applications Manager 9.4.1

For the prompt: Do the following:

Tomcat Web Server installed on this machine To:
[Yes]
• Share an Tomcat Web server with the RMI server
installed with the Automation Engine, enter N.
When you share an Apache Web server:
• The RMIHostID set in the Options.properties
files must be a DNS name that resolves
across all servers.
• The Apache Web server should be on a
separate machine than either RMI server.
• Install a separate Apache Web server for this
RMI server, accept the default of Yes.
You might want to have separate Apache Web
servers if you want different values set for the
RMIHostID in each Options.properties files. In
this case, you can install the Apache Web servers
on the same machines as the RMI servers.
• For Windows: Uncheck the Install Automation Engine Local Agent checkbox on the first screen.
Warning: The awenv.ini file for this RMI server will include an agent line with the name of the
Automation Engine as its value. Do not delete this line, or the awcomm process will not start.

You must have AW_RMI_ONLY set in the sosite file. This is set automatically by the installation script in order
to prevent the start of an AgentService process.
If you ever want to add a Local Agent to the RMI server, you can re-run the installation script, and enter Y for the
Install Automation Engine's Agent prompt.
2. In the awenv.ini file for each AgentService, add the line for the failover RMI server:

alt_master_ip_address=<IP address>

3. Specify the new RMI server as an allowable RMI server by designating it as a master on the RMI Servers tab of
the Connections window in the Applications Manager client.

The Connections window is limited to Users who have the DBA User Group. If you do not have access to it,
see your Applications Manager administrator.
In the image above, the Automation Engine is shown at the top of the table. Its session ID is 3025715. Its
corresponding RMI server (RmiServer) has the same session ID. The Automation Engine's Local Agent is
named V9AM01 and displays the same IP address as the Automation Engine's RMI server. The final item is the
second RMI server.
The last column in the table, Master, applies only to the RMI servers. If "Ok" is displayed in the column, it
indicates that the RMI server can support the Automation Engine.
 Applications Manager 9.4.1

To activate an RMI server to serve the Automation Engine, double-click the entry in the table. This will toggle the
entry from "No" to "Ok". To toggle the entry back to "No", double-click it again.
RMI Failover Behavior
The Applications Manager Automation Engine supports active-passive failover. A secondary Applications
Manager RMI server can be setup and run in stand-by mode (active-passive), so that in the event that the primary
Applications Manager Automation Engine goes down, the stand-by RMI server will become the active Automation
Engine. When the stand-by RMI server becomes active, the Agents will reconnect to it automatically; with the
exception of the Local Agent. That is because the Local Agent is part of the Automation Engine installation, and
integrated with the specific Automation Engine system. Therefore, in systems that require RMI server failover, it is
recommended that all Jobs be setup to run on Remote Agents.

Installing a UNIX Remote Agent

Remote Agents allow you to run tasks on servers other than the server where the Applications Manager
Automation Engine is installed.
If you want to run UNIX tasks on a server other than the server where the Applications Manager Automation Engine
is installed, you must install an Applications Manager Remote Agent on the other server. You can have as many
Remote Agents as needed.
Steps
The basic steps for installing a UNIX Remote Agent are:
1. Define the Remote Agent in Applications Manager.
2. Install the Applications Manager Remote Agent software.
3. Verify the installation.
Before You Begin
Before you begin the installation, you need the following information:
• Applications Manager Remote Agent UNIX account login and password
• Network IP address for the Remote Agent host
• Network IP address for the Automation Engine host
• Agent name for the Automation Engine that will control the Remote Agent
• A name (up to 100 characters) for the Applications Manager Remote Agent
When selecting a name for the Agent, do not use any of the following names: ALL, AWCOMM, AGENTSERVICE,
RMI, RMISERVER, AGENT, or MASTER. These are Applications Manager process names, and if used, can cause
problems with start and stop commands issued by Applications Manager.
An Applications Manager Remote Agent does not require a separate database account. All Applications Manager
data is stored in the repository used by the Automation Engine.
It is possible to install Remote Agents on the same machine as an Automation Engine/Local Agent. To do so, you
just need to install the Remote Agent as a separate OS user and/or use a different IP address/host name when
defining the Agent in the Applications Manager client.
Accessing the Remote Agent Through a Firewall
When running the Remote Agent install script, you will be asked if you have a firewall installed. If you answer yes,
you will be able to specify values for the following ports:
• Agent Server Port
• Agent Client Port
• Stack Server Port
• Stack Client Port
It is a good idea to specify the same port numbers on each Remote Agent to minimize the number of ports you
have to keep open on the Automation Engine's firewall.
After specifying port numbers for the Remote Agent (as well as for the Automation Engine), you must open the
appropriate ports in your firewall software on the Automation Engine/RMI server, Agent, and client. If you need to
change your firewall ports, you can do so by re-running the install script. For more information on the ports you
need to open for inbound and outbound firewalls. For more information, see Overview of Firewall Settings.
 Applications Manager 9.4.1

Defining the UNIX Remote Agent in Applications Manager

You can add Remote Agents by adding an Agent object in Applications Manager and running an install script.
Remote Agents are used to run tasks on a machine that does not include the Applications Manager Automation
Engine.
The first step to install a Remote Agent is to define the Agent in Applications Manager. If you do not define the
Agent in Applications Manager, the install script will fail.

Adding Remote Agents

To add a Remote Agent object:
1. Open the Object Admin menu, and choose Agents.
Applications Manager displays the Agents Selector window shown above.
2. On the Agents Selector window, click the New button.
Applications Manager opens the Select Agent Type window.
3. Select STANDARD and click OK.
4. Fill in the fields and click OK to save.
Some important fields to know about when defining a new Remote Agent are described below. For a description
of all fields on the Agents window, click the Help button.
• Name
 Applications Manager 9.4.1

The name can be up to 30 characters long. If you install two or more Remote Agents on a machine, do not
give them the same name (even if they report to different Automation Engine instances). The following are
reserved words that cannot be used for Automation Engine or Agent names: ALL, APPWORX, AWCOMM,
AGENTSERVICE, AWAPI, RMI, RMISERVER, AGENT, and MASTER.
• Description
A description of an Agent can be up to 30 characters long.
• IP address
The IP address or DNS name.
• CPU Limit
Defines the percentage of CPU usage where Applications Manager will spawn no new tasks. When an Agent
reaches its CPU limit it will go into a CPU WAIT Agent status. Tasks waiting to run on an Agent that has
reached its CPU limit will go to an AGENT WAIT status. The default is 80% for newly created Agents or 99%
for Agents that were upgraded from a version of Applications Manager before this feature existed. You can
see actual CPU usage percentages for Agents in the Cpu column on the Agent Summary on the Explorer
window. The CPU usage is updated about once every minute for each Agent and the Automation Engine.
• Thread Schedule
Sets the maximum number of concurrent tasks that can run on the Agent at one time in all Queues.
Editing the Thread Schedule of the Automation Engine/Local Agent from this field will change the setting for
only the Local Agent.
Thread Schedules can be changed for the Automation Engine and Agents from the Explorer window.
• OS type
Indicates that the operating system is UNIX.
• User
The operating system user for the Agent. The User selected determines the Awexe range assigned to the
Agent. Be sure your Agents are assigned to a User with the full Awexe range, which is 1000-9999. Users
assigned to a Remote Agent require an Awexe range for the Agent to start.
Warning: This User should never be SQLOPER.

Defining Multiple Agents on the Same Instance

To define multiple Agents on the same instance, simply create additional Agent objects with the same IP address
and User. You will only need to run the Agent install the first time.
If you have two or more Agent installs on the same remote machine from a previous Applications Manager version,
it is necessary to assign them each a unique OS user.

Installing the Remote Agent

The second step is to install the Remote Agent by running the CDINST.SH script.
After defining the Remote Agent in Applications Manager, the next step is to install the Remote Agent by running
the CDINST.SH script on the remote host.
In the event an Agent makes a database connection directly (i.e. OAE Agent, Banner Agent, or any direct database
connection), you need to copy the ojdbc6.jar file to the $AW_HOME/web/classes directory of the Agent. You can
get that file from your ORACLE_HOME/jdbc/lib/ directory or the Oracle website.
Run the Install Script
On the host where you want to install the Agent, run CDINST.SH from a staging directory. The installation script
creates the required directories and moves the programs into the proper directories.
During the installation process, Applications Manager displays default values in brackets [ ]. The values will be
different for each system. You can accept the default values by pressing the Enter key at the prompt, or override
the default values by typing in a response and pressing the Enter key.
Procedure
To install an Applications Manager UNIX Remote Agent:
 Applications Manager 9.4.1

1. Log into the Applications Manager UNIX account on the remote host, and if necessary, change to the directory
where you want the Applications Manager Remote Agent installed.
You must be logged into the Applications Manager UNIX account and be in the Applications Manager directory
for the installation procedure to work correctly. Moving the files after the installation is complete requires some
effort. It is best to install into the correct directory in the first place.
If you transferred files to a staging directory, verify that all the Applications Manager files are owned by the
Applications Manager UNIX login and group. If they are not, the installation will fail. Use the chown and chgrp
commands to modify the ownership if necessary.
2. From the directory in which you want the Agent installed, run CDINST.SH on the host.
Be sure to set permissions for the CDINST.SH file.
After completing the initial install, you can run agentinstall and bypass cdinst by typing:

sh agentinstall

The agentinstall program can be used to modify the current agent-related parameters for the Applications
Manager installation.
3. Follow the onscreen prompts.
4. After completing the installation script, enter the command as shown below to establish the proper environment,
or log out of UNIX and back in.

. .profile

The following lines have been added to $AW_HOME/.profile during the installation process:

AW_HOME=/apps/appworx_a;export AW_HOME
. /apps/appworx_a/site/sosite

Assign Applications Manager Environment Variables in sosite, not in .profile.

5. Start the Applications Manager processes using the startso command on the Remote Agent.
Verifying the Installation
After you complete the installation, start the Applications Manager network listener, obtain the authorization key,
and start the Applications Manager Automation Engine and Agent processes/services, you should verify that the
Applications Manager Remote Agent is installed correctly and ready to start processing tasks. A good test is to run
an Applications Manager Job, such as TEST_JOB on the Remote Agent and view its output files.
For detailed instructions on running the TEST_JOB, see Verifying the Installation.
Installation Complete
You have verified the Remote Agent. This is the last step in the installation procedure

Installing a Windows Remote Agent

Remote Agents allow you to run tasks on servers other than the server where the Applications Manager
Automation Engines is installed.
If you want Applications Manager to run tasks on a Windows server other than the Applications Manager
Automation Engine server, you must install an Applications Manager Remote Agent on the server. You can have as
many Remote Agents as needed.
Steps
The basic steps for installing an Windows Remote Agent are:
 Applications Manager 9.4.1

1. Define the Remote Agent in Applications Manager.

2. Create the Windows user.
3. Install the Applications Manager Remote Agent software.
4. Verify the installation.
Windows System Requirements
The Applications Manager Windows system requirements are described below. You should make sure you have
the necessary free disk space before proceeding.

Component Min. Disk Space Required Recommended Disk Space

Installation files and temporary files 80 MB 110 MB

created during installation

Operations files 10+ MB Varies*

* There must be enough disk space to hold all the output (reports and system listings) for the retention period of the
Job.
Accessing the Remote Agent Through a Firewall
When running the Remote Agent install script, you will be asked if you have a firewall installed. If you answer yes,
you will be able to specify values for the following ports:
• Agent Server Port
• Agent Client Port
• Stack Server Port
• Stack Client Port
It is a good idea to specify the same port numbers on each Remote Agent to minimize the number of ports you
have to keep open on the Automation Engine's firewall.
After specifying port numbers for the Remote Agent (as well as for the Automation Engine), you must open the
appropriate ports in your firewall software on the Automation Engine/RMI server, Agent, and client. If you need to
change your firewall ports, you can do so by re-running the install script. For more information on the ports you
need to open for inbound and outbound firewalls, see Overview of Firewall Settings.

Defining the Windows Remote Agent in Applications Manager

You can add Remote Agents by adding an Agent object in Applications Manager and running an install script.
Remote Agents are used to run tasks on a machine that does not include the Applications Manager Automation
Engine.
The first step to installing a Remote Agent is to define the Agent in Applications Manager. If you do not define the
Agent in Applications Manager, the install script will fail.
 Applications Manager 9.4.1

Adding Remote Agents

1. Open the Object Admin menu, and choose Agents.
Applications Manager displays the Agents Selector window shown above.
2. On the Agents Selector window, click the New button.
Applications Manager opens the Select agent type window.
3. Select STANDARD and click OK.
4. Fill in the fields and click OK to save.
Some important fields to know about when defining a new Remote Agent are described below. For a description
of all fields on the Agents window, click the Help button.
• Name
The name can be up to 30 characters long. If you install two or more Remote Agents on a machine, do not
give them the same name (even if they report to different Automation Engine instances). The following are
reserved words that cannot be used for Automation Engine or Agent names; ALL, APPWORX, AWCOMM,
AGENTSERVICE, AWAPI, RMI, RMISERVER, AGENT, and MASTER.
• Description
A description of an Agent can be up to 30 characters long.
• IP address
 Applications Manager 9.4.1

The IP address or DNS name.

• CPU Limit
Defines the percentage of CPU usage where Applications Manager will spawn no new tasks. When an Agent
reaches its CPU limit it will go into a CPU WAIT Agent status. Tasks waiting to run on an Agent that has
reached its CPU limit will go to a AGENT WAIT status. The default is 80% for newly created Agents or 99%
for Agents that were upgraded from a version of Applications Manager before this feature existed. You can
see actual CPU usage percentages for Agents in the Cpu column on the Agent Summary on the Explorer
window. The CPU usage is updated about once every minute for each Agent and the Automation Engine.
• Thread Schedule
Sets the maximum number of concurrent tasks that can run on the Agent at one time in all Queues.
Editing the Thread Schedule of the Automation Engine/Local Agent from this field will change the setting for
only the Local Agent.
Thread Schedules can be changed for the Automation Engine and Agents from the Explorer window.
• OS type
Indicates that the operating system is Windows.
• User
The operating system user for the Agent. The User selected determines the Awexe range assigned to the
Agent. Be sure your Agents are assigned to a User with the full Awexe range, which is 1000-9999. Users
assigned to a Remote Agent require an Awexe range for the Agent to start.
Warning: This User should never be SQLOPER.

Defining Multiple Agents on the Same Instance

To define multiple Agents on the same instance, simply create additional Agent objects with the same IP address
and User. You will only need to run the Agent install the first time.
If you have two or more Agent installs on the same remote machine from a previous Applications Manager version,
it is necessary to assign them each a unique OS user.

Creating the Windows User

The Windows Agent runs as a Windows service and should run as the local Windows Administrator account.
After adding the Remote Agent, the next step is to create the Windows user.
The Applications Manager Windows WatchWorx service runs as Windows service. We recommend that each
service run as a specific Windows user: typically the Administrator user. Whichever user the services run as, that
user must have certain advanced user rights and permissions. Administrator is the default User when installing this
service.
Required Permissions
The table below identifies the rights and permissions required for the Administrator, custom-built user (or custom
Applications Manager), and the domain user.

User Rights and Permissions

Administrator (recommended) or Applications Manager • Advanced User Right: act as part of the operating
system
• Advanced User Right: log on as a service
• File access permissions to run the programs you
wish to run with this Automation Engine and Local
Agent.
 Applications Manager 9.4.1

User Rights and Permissions

Domain/User • Advanced User Right: Act as part of the operating

system
• Advanced User Right: Log on as a service
• File access permissions to run the programs you
wish to run with this Automation Engine and Local
Agent.
• Must belong to the domain/administrator group.

Remember, you must log out and log in again after changing any user rights. Otherwise, the changes will not
take effect. You should determine which user(s) the Applications Manager services are going to run as before
proceeding with the installation. You will perform the installation as Administrator.
Special Circumstances
Occasionally, certain Windows host configurations do not allow the Applications Manager services to be installed to
a specific User/Password. If you are unable to install the Applications Manager services as a specific user on your
Windows host, Applications Manager recommends that you do the following:
1. Install Windows Remote Agent and Network Listener Services; however, leave the User and Password fields
blank. By default Applications Manager installs into the System user account.
2. After you complete the installation, go to the Windows Services and locate the AWW-<Agent name> service.
3. Ensure that the AWW-<Agent name> service's Startup Type option is set to 'Automatic'.
4. Change the Log On As from 'System Account' to 'This Account.' Enter the Windows user account and the
password.
5. Be sure to update the service with an appropriate Windows user name and password.

Running the Installation Program

To install an Windows Remote Agent, run the installation executable. If you are installing from a CD, use
cdinstall.bat. If not, then open a command prompt, go to the site directory, call sosite.bat, then awinstall. After
completing the installation, you will have one Remote Agent installed on the host.
After defining the Remote Agent in Agent Manager and adding the operating system user in Login Manager, you
are ready to install the Remote Agent.
In the event an Agent makes a database connection directly (i.e. OAE Agent, Banner Agent, or any direct database
connection), you need to copy the ojdbc6.jar file to the $AW_HOME/web/classes directory of the Agent. You can
get that file from your ORACLE_HOME/jdbc/lib/ directory or the Oracle website.
Before You Begin
Before you begin the installation, you need the following information:
• The logon name and password for each User under which you are going to run an Applications Manager service
• The network IP address for the Remote Agent host
• The network IP address for the Automation Engine host
• The name for the Automation Engine that will control the Remote Agent
• A name (up to 100 characters) for the Applications Manager Remote Agent
An Applications Manager Remote Agent does not require a separate database account. All Applications Manager
data is stored in the repository used by the Automation Engine.
It is possible to install Remote Agents on the same machine as an Automation Engine/Local Agent. To do so, you
just need to install the Remote Agent as a separate OS user and/or use a different IP address/host name when
defining the Agent in the Applications Manager client.
Install Program
The cdinstall.bat program installs the Windows Remote Agent. You should run the program as Administrator. The
Remote Agent install program:
• Installs the Applications Manager files in the appropriate directories.
• Sets up and updates the database tables, Windows services, and other Applications Manager-specific files.
Procedure
 Applications Manager 9.4.1

To install an Applications Manager Windows Remote Agent:

1. While logged in as Administrator, run the cdinstall.bat program.
2. Follow the on-screen prompts.
It is recommended to install in a directory without spaces. Depending on your Windows system configuration
issues for pathing, it can cause issues if you install in a directory with spaces.
3. If required, assign Applications Manager Environment Variables in envvar.bat.
For example, you may need to define Oracle Applications environment variables.
Verifying the Installation
After you complete the installation, start the Applications Manager network listener, obtain the authorization key,
and start the Applications Manager Automation Engine and Agent processes/services, you should verify that the
Applications Manager Remote Agent is installed correctly and ready to start processing tasks. A good test is to run
an Applications Manager Job, such as TEST_JOB on the Remote Agent and view its output files.
For detailed instructions on running the TEST_JOB, see topic Verifying the Installation.

Upgrading Applications Manager

When you upgrade an Automation Engine and its Local Agent, you must also upgrade all Remote Agents
controlled by that Automation Engine to ensure that the Automation Engine and all its Agents are the same version.
To upgrade a UNIX or Windows Automation Engine, you run the Applications Manager installation script. The
script upgrades the Automation Engine and its Local Agent to a new version of Applications Manager. If you are
upgrading a host with multiple Agents, the Applications Manager communication processes (aw*) will not be
replaced unless they are assigned write access.
To upgrade a Remote Agent, you run the Remote Agent install script awagentinstall. The script upgrades your
Remote Agent to a new version of Applications Manager.
Rule-Based Optimization
Applications Manager is designed to take advantage of rule-based optimization. It is recommended the database
be started using rule-based optimization to enhance the performance of Applications Manager. In high load
scenarios, the database must run in rule-based mode.
Changes in Behavior
Changes in behavior are described in the
Applications Manager v9.x Release Highlights
.
Default Objects Overwritten
If you have modified any of the Applications Manager default objects or scripts, they will be overwritten during the
upgrade. For example, you may have modified a Program Type, or modified a Program Type script in the exec
directory.
If you modified a default object, you will need to redefine it after the upgrade. Long term, you should consider
creating unique Program Types that will not be overwritten.
If you modified a script, you can copy the script to a different directory, run the upgrade, then copy the script back to
the original directory. As with the default objects, you should consider creating uniquely named scripts that will not
be overwritten.

Upgrading or updating Tomcat

This article describes how you can manually upgrade or update the Tomcat.

Manually update Tomcat files

To use an existing Tomcat with AM, server.xml and web.xml files must be updated after Applications Manager (AM)
is installed.
Note: Restart Tomcat after updating the configuration files.

1. Backup {Tomcat_home}/conf/server.xml.
 Applications Manager 9.4.1

2. Add xmlValidation=”false” and xmlNameSpaceware=”false” in the <Host> attribute.

<Host name="{fully qualified machine name}" appBase="webapps"

unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">

3. Add <Context path> attribute where path={AM Master} and docBase={location of AM web
folder}

<Context path="/AM_DEV"
docBase="C:/AM_DEV/web/"
reloadable="true"
crossContext="true"/>

Manually upgrade Tomcat

Note: You can install multiple versions of Tomcat in one machine.
Scenario 1: Install the latest Tomcat on a new location and use a new port. Refer to Manually updating Tomcat
Files on how to update the configuration files.
Scenario 2: Install the latest Tomcat on a new location and use the same port as the existing Tomcat. Stop the
existing Tomcat before installing the new Tomcat. Refer to Manually updating Tomcat Files on how to update the
configuration files.
Scenario 3: Install Tomcat on the same location, using the same port and service name as the existing Tomcat.
To perform scenario 3:
1. Stop the Tomcat service.
Non-Windows: tomcat_home/bin/shutdown.sh.
Windows: open "Configure Tomcat" or run: tomcat_home/bin/shutdown.bat or run: sc stop {Tomcat
service name}
2. For Windows only: Remove Tomcat service
{tomcat_home}\bin>Tomcat10 //DS//{Tomcat service name}
3. Backup the bin, conf, and webapps folders.
4. Delete contents of old Tomcat installation from {Tomcat_home}.
5. On Windows: Run the new Tomcat executable. In “Destination Folder” replace the default location with the
existing/current Tomcat location.
Existing location: C:\Program Files (x86)\Apache Software Foundation\Tomcat
10.0_Tomcat10Test2
Change To: C:\Tomcat\Tomcat10Test2
Non-Windows: un-compress tomcat*.tar.gz in the existing/current Tomcat location.
6. Note: Ensure Tomcat is stopped.
After the installation is complete, replace conf, webapps, work folders with the backup folders of Step 3.
7. Start Tomcat.

Upgrading an Automation Engine and Local Agent

This procedure describes how to upgrade an Applications Manager Automation Engine and its Local Agent. When
you upgrade an Automation Engine and its Local Agent, you must also upgrade all Remote Agents controlled
by that Automation Engine to ensure that the Automation Engine and all its Agents are the same version. For
information on upgrading a Remote Agents, see Upgrading Remote Agents.
Before You Begin
 Applications Manager 9.4.1

Before you begin the upgrade, stop the Applications Manager processes and back up the Applications Manager
database account.
Make sure you have the following information before proceeding:
• The Applications Manager UNIX account login and password or the Applications Manager Windows
administrator login.
• The Applications Manager Database Login and password
Procedure
To upgrade an Applications Manager Automation Engine and Local Agent:
1. Stop all Applications Manager processes, including awcomm. You can kill all Applications Manager processes
by issuing the following commands:

stopso all
stopso awcomm

If you have multiple RMI servers installed for RMI failover, you must stop the RmiServer processes on all
machines where they are running.
2. Log into the Applications Manager account, and if necessary, change to the directory where Applications
Manager is installed.
In UNIX, you must be logged into the Applications Manager UNIX account and be in the Applications Manager
directory for the installation procedure to work correctly. If you transferred files to a staging directory, verify
that all the Applications Manager files are owned by the Applications Manager UNIX login and group before
running the install script. If they are not, the upgrade will fail. Use the chown and chgrp commands to modify
the ownership if necessary.
3. From the directory in which you want Applications Manager installed, run the installation script. In UNIX, the
script is CDINST.SH. In Windows, it is cdinstall.bat.
4. Follow the onscreen prompts.
Note that the required information for an install/upgrade may have changed since you first installed Applications
Manager. For more information on the current requirements, see System Information Required for the
Installation.
5. When presented with the menu of upgrade options, choose:

Initial Install/Upgrade from prior version.

6. Follow the onscreen prompts.

Note that the required information for an install/upgrade may have changed since you first installed Applications
Manager. For more information on the current requirements, see System Information Required for the
Installation.
UNIX Systems
For UNIX systems, you should complete the following steps:
1. After completing the install and exiting the script, enter the following command to establish the proper
environment, or log out of UNIX and back in:

. .profile
chmod 4711 c/SURUN
chown root c/SURUN
 Applications Manager 9.4.1

2. If you are using surun, make sure you move the surun file to the SURUN directory. From the User account
$AW_HOME/c directory, type:

mv c/surun c/SURUN

3. Restart your Applications Manager processes.

Next Step
You have completed upgrading the Applications Manager Automation Engine and Local Agent. The next step is to
upgrade any Applications Manager Remote Agents as described in Upgrading Remote Agents. If you do not have
Remote Agents, skip to Verifying the Upgrade.

Upgrading Remote Agents

This procedure describes how to upgrade an Applications Manager Remote Agent on a single host. When you
upgrade an Automation Engine and its Local Agent, you must also upgrade all Remote Agents controlled by that
Automation Engine to ensure that the Automation Engine and all its Agents are the same version.
In the event an Agent makes a database connection directly (i.e. OAE Agent, Banner Agent, or any direct database
connection), you need to copy the ojdbc6.jar file to the $AW_HOME/web/classes directory of the Agent. You can
get that file from your ORACLE_HOME/jdbc/lib/ directory or the Oracle website.
Before You Begin
Before you begin the upgrade, delete all tasks from the Backlog and stop the Applications Manager processes. You
can do this by issuing the stopso command from the command line prompt.
For UNIX, make sure you know the Applications Manager Remote Agent UNIX account login and password before
you begin.
Running the Upgrade Script
The upgrade script for the Remote Agent is CDINST.SH for UNIX and cdinstall.bat for Windows.
In UNIX, Applications Manager displays default values in brackets [ ]. You can accept a default by pressing ENTER
at a prompt.
In Windows, Applications Manager displays a series of screens that prompt for information.
Java is not automatically upgraded for Windows Remote Agent upgrades, because there are system-wide effects.
Java upgrades on Windows Remote Agent machine must be done manually.
Procedure
To upgrade an Applications Manager Remote Agent:
1. Log into the Applications Manager account on the Remote Agent machine, and if necessary, change to the
directory where Applications Manager is installed.
In UNIX, you must be logged into the Applications Manager UNIX account and be in the Applications Manager
directory for the installation procedure to work correctly. If you transferred files to a staging directory prior to
running the install script, verify that all the Applications Manager files are owned by the Applications Manager
UNIX login and group. If they are not, the installation will fail. Use the chown and chgrp commands to modify
the ownership if necessary.
In Windows, you must be logged in as Administrator.
2. From the directory in which you want the Agent installed, run the installation script:
UNIX:

CDINST.SH
 Applications Manager 9.4.1

Windows:

cdinstall.bat

Be sure to set permissions for the CDINST.SH file.

If you need to re-run the installation, you can run the agentinstall file and skip the file transfer steps.
3. Follow the onscreen prompts.
4. When presented with the menu of upgrade options, choose:

Initial Install/Upgrade from prior version.

5. Continue to follow the onscreen prompts.

UNIX Systems
For UNIX systems, you should complete the following steps:
1. After completing the install and exiting the script, enter the following command to establish the proper
environment, or log out of UNIX and back in:

. .profile
chmod 4711 c/SURUN
chown root c/SURUN

2. If you are using surun, make sure you move the surun file to the SURUN directory. From the User account
$AW_HOME/c directory, type:

mv c/surun c/SURUN

3. Restart your Applications Manager processes.

Next Step
You have upgraded the Remote Agent. The next step is to verify the upgrade.

Verifying the Upgrade

After completing the upgrade, you should verify that Applications Manager is installed correctly and ready to start
processing tasks. A good test is to run a Job and view its output files.
Procedure
To verify the installation:
1. Start the Applications Manager Automation Engine and Agent processes.
2. Run the TEST_JOB and monitor the progress of TEST_JOB in the Backlog.
The TEST_JOB should complete successfully with status FINISHED.
3. View the output.
Verifying the Remote Agent Upgrades
If you upgraded one or more Remote Agents, run through the above process using test Jobs designated to run on
the Remote Agents. Make sure the test_module program is located on the Remote Agent machine.
Verification Complete
 Applications Manager 9.4.1

If TEST_JOB finished and you can view the output file, then Applications Manager has been upgraded correctly.
Verification is complete.

Loading Rapid Automation Component .jar Files into

Applications Manager
You load Rapid Automation Agent component .jar files into Applications Manager with the Rapid Automation loader.
Using the Rapid Automation Loader
To use the Rapid Automation Loader:
1. Go to the Tools menu and select Rapid Automation Loader.
Applications Manager opens the Rapid Automation Loader window shown below.

2. From the Rapid Automation Loader window, browse to a directory where RA components are on your PC
using the Browse button.
3. Select a component from the Available Components box.
4. Optionally enter an ID number for the component in the ID field. If you don’t enter an ID number the next
available number will be used.
In most cases you would not need to worry about ID numbers. You would only need to set one in rare cases
such as when an Agent with references is deleted out of the database and it needs to be recreated with the
same number in the SO_OPERATORS table.
5. Click OK or Apply.
OK saves the changes and closes the window. Apply saves the changes and keeps the window open. In either
case a confirmation window will tell you that the component was loaded and the component will be added to the
Loaded Components box.
You will now be able to define Agents of this type in Applications Manager.
6. If you are upgrading an existing RA Agent type that you have Agents defined for, you must stop and restart the
AgentService process for all previously defined Agents.
7. For some Agents, such as Business Objects, you must log out and log back in to the Applications Manager
Client.
Deleting Loaded Components
To delete a loaded component, select the component and click Delete. In order to delete a component, you must
first delete any objects from Applications Manager that reference this component.
Comparing Build Information
To compare build information between available and loaded components, select an available component from
your PC in the Available Components box and a loaded component from the Loaded Components box and
click Build Info. Applications Manager opens the Build Info window shown below where you can compare the
information for the two builds.
 Applications Manager 9.4.1

Adding Alternate Classes to Your Path

If you want to include alternate class files to the beginning of your CLASSPATH environment variable on start-up,
add them to the following directory.
UNIX:

$AW_HOME/web/classes_alt

Windows:

%AW_HOME%\web\classes_alt

After adding additional files to the classes_alt directory, you must stop and restart process by going to the site
directory and issuing the following commands:
UNIX:

. sosite
stopso
startso

Windows:

sosite
stopso
startso
 Applications Manager 9.4.1

6 User Guide
The User Guide is a comprehensive procedures manual that covers all aspects of Applications
Manager operations.
The User Guide is a comprehensive procedures manual that covers all aspects of Applications Manager
operations. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

About This Guide

The User Guide is a comprehensive procedures manual that covers all aspects of Applications Manager
operations. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Applications Manager Operations

Applications Manager provides robust operations tools that make it easy for you to monitor and manage tasks as
they execute. As a Applications Manager operator, you can:
• Monitor the system.
• Handle exceptions to normal processing.
• Run tasks on an as-needed basis.
• View and print task output.
• See what tasks will run during your shift.
 Applications Manager 9.4.1

• Control load on the system.

• Troubleshoot tasks.
• Prevent tasks from launching.
• Take actions on tasks.
• Run tasks from the command line.
• Stage tasks up to 48 hours ahead.
Each of the areas of Applications Manager used by operators is described briefly below. Details for each are given
in the remainder of this chapter and the chapters that follow.
Using the Explorer Window
The Explorer window is the primary tool you use to monitor and manage Agents, Queues, and tasks. A sample
Explorer window is shown below.

Viewing Forecasts
Using the forecast feature, you can view a list of scheduled Jobs and Process Flows.
Requesting Jobs and Process Flows
There may be times when you want to run tasks outside of a set schedule. You can submit individual Jobs and
Process Flows from the Requests window. In Applications Manager, we refer to these as "ad hoc" requests.
Using Gantt Windows
You can use the following operations Gantt windows:
 Applications Manager 9.4.1

• Graphical Forecast: Displays scheduled Jobs and Process Flows in a Gantt chart format.
• Backlog Gantt View: Displays the contents of the Backlog in a real-time Gantt chart format. You can take
actions on tasks or view/edit their task details.
• History Gantt View: Displays in Gantt chart format how the components of a Process Flow in the History
executed.
Viewing Operations Reports
Applications Manager comes with a set of predefined Reports that provide information about your Applications
Manager objects. You can also import an extensive set of Applications Manager History Analysis Reports that you
can use to review how tasks were processed. You can also create your own custom Reports.

Using the Applications Manager Desktop

You can access all Applications Manager features and options from the Applications Manager desktop.
 Applications Manager 9.4.1

If you are using a Windows client with 800x600 resolution, you will need to select the Windows auto hide taskbar
option.
ToolTips
ToolTips provide a brief description of buttons, icons, and fields. To see a ToolTip, rest the mouse pointer over the
button, icon, or field. A ToolTip appears after the mouse pointer has remained motionless for a second or two. In
the image above, the mouse pointer is resting on the Jobs icon in the toolbar. You can disable ToolTips by going to
the View menu and unchecking the ToolTips option.
Toolbar and Menus
 Applications Manager 9.4.1

The toolbar consists of a row of icons running across the top of the screen. Click an icon to open its corresponding
window. You can also access the windows in the toolbar from the Operations and Object Admin menu items. The
Activities menu listings open windows where you can take actions such as opening Explorer or running ad hoc
tasks with Requests. The Object Admin menu listings open selector windows where you can view, add, edit, or
delete object definitions (depending on your User Group access).
You can view or hide the toolbar by opening the View menu and checking/unchecking the Toolbar option. You can
optionally view text for the toolbar options by opening the View menu and checking/unchecking the Toolbar Text
option. You can add or remove the icons displayed on the toolbar by selecting Settings from the Options menu.
For instructions on editing desktop settings, see Editing General Desktop and ToolBar Settings.
Taskbar
The taskbar is a graphic bar running across the bottom of the desktop that is used to select active windows. When
you open an Applications Manager editing window, the window is represented by an icon in the taskbar. From the
taskbar, you can right-click a window icon to:
• Restore a window to the desktop or minimize it to the taskbar. You can also display an active window by
opening the View menu, selecting Windows, and choosing a window.
• Maximize a window to fill the desktop.
• Move a window to the front of the desktop.
• Close a window.
Selector windows are used when defining Applications Manager objects. They are not displayed on the taskbar
because they do not contain unique information and are represented by icons on the toolbar.
Status Bar
The status bar is displayed across the bottom of the Explorer window. Its color alerts you to the status of the
Automation Engine, Agents, and tasks running in the Backlog. When the Explorer window is minimized it uses the
same color scheme on the taskbar. For more information on the status bar, see Monitoring with the Status Bar and
Object Icons.
Closing All Windows or Selector Windows
To close all windows, go to the View menu and select Close all. To close only the selector windows, select Close
selectors.

Working in the Applications Manager Windows

In many of the Applications Manager windows, the columns can be sorted and rearranged. Applications Manager
conforms to most GUI standards, including keyboard navigation.
Sorting Columns
You can display the items within a column in ascending or descending order. Click the header of a desired column
to view its entries in descending order. Click a second time to view the entries in ascending order. Note that the
arrow to the right of the column name reflects this change. Some columns can be clicked a third time to display the
entries in their default order. The arrow may be displayed in a separate column, or not at all, when entries are in
their default order. You can click the columns additional times to cycle through the options.
Copying Text from Rows
To copy text from a table in an Applications Manager window, click one or more rows and enter Ctrl-C. You must
select the entire row. You can then paste the text into an email, word processor, or other application of your choice.
Temporarily Changing Column Order
To temporarily change the order of the columns, use the mouse to point to the heading of the column you want to
move, hold down the mouse button, and drag the column to the new position as shown below.
 Applications Manager 9.4.1

These settings are not retained when you close the window. Many columns can be configured and saved. For more
information, see Customizing Tables.
Copying, Cutting, and Pasting Text
You can right-click in a field to bring up a pop-up menu with copy, cut, and paste options.
Bringing Error Dialogs into View
If you minimize the Applications Manager desktop when an error message is displayed, the Applications Manager
desktop may seem to lock up. This is because the error dialog is out of view. To bring the error dialog back into
view, hold down the Alt key and press the Tab key until you highlight the Java coffee cup icon.
Keyboard Navigation
You can use the following keyboard navigation in Applications Manager:
• Ctrl-Up arrow key sets the focus on the current tab, then the right and left arrow keys will navigate to the other
tabs. Ctrl-Down arrow key returns focus to the page.
• If a table has focus, then Ctrl-Tab will move the focus out of the table.
• When you are in a table, Enter and Tab are used for navigation within the table.
• To alternately expand and collapse an object's key, press Enter.
• To select a mnemonic key, click Alt+<the key>.
Assigning Options
When required, you assign options and objects using the type of window shown below.
 Applications Manager 9.4.1

Assign objects by moving them from the Unassigned column to the Assigned column. The table below describes
how to assign multiple options.

To: Do this:

Move a selected value between the two columns Double-click the value.
-or-
Select the value and click the single arrow button.

Move all values between the two columns Click on the double arrow button.

Make multiple contiguous selections Hold down the Shift key and click the first and last
values.

Make multiple nonadjacent selections Hold down the Control key and click on each value.

Editing General Desktop and ToolBar Settings

You can edit and save general, toolbar, and alert desktop settings. These settings apply only to your workstation
while you are logged in to an Applications Manager session.
 Applications Manager 9.4.1

Editing General and Toolbar Settings

To set the Applications Manager desktop settings:
1. From the Options menu, choose Settings.
Applications Manager displays the General tab of the Settings window shown on the left in the image above.
The settings are described below.
• Explorer Refresh Seconds
You control the Explorer window's automatic refresh rate by entering a number of seconds in this field. In the
image above, the refresh frequency is set to 10 seconds (the lowest number of seconds available). You can
also manually refresh by entering Ctrl-R or by clicking the status bar on the Explorer window.
• History Display Minutes
You control how long records are displayed in History using the Previous minutes field. For example, if you
set Previous minutes to 60, only tasks that have run within the last 60 minutes will be displayed.
In some cases records will remain in History beyond this setting due to predecessor requirements.
In the image above, the Previous minutes field is set to 30.
The amount of History displayed when you log in to the client is determined by the HistoryRetentionTime
setting in the Options.properties file. For more information on the HistoryRetentionTime setting and the
Options.properties file.
Caution! The higher you set your Previous minutes, the more memory you will use. You can always run a
History query to view older tasks in History. For more information on History queries, see topic Querying for
Tasks in History.
• Use Database Time Zone
If this option is selected, times shown in the Submit window are based on the time set for the Applications
Manager database. If it is not selected, then the times shown in the Submitwindow are local time based on
the client machine. This is translated to database time for running the task.
Times shown in the Backlog, History, on the status bar, and in the lower right corner of the Explorer screen
are always in database time.
2. You can customize the toolbar by adding and removing icons. To add or remove icons on the toolbar, select the
Toolbar tab shown on the right in the image above.
3. To move items between the Unassigned and Assigned columns, double-click or use the arrow keys.
For details on assigning and unassigning values, see Working in the Applications Manager Windows.
 Applications Manager 9.4.1

4. You can set alerts in Applications Manager that are triggered by the status of tasks in the Backlog by selecting
the Alerts tab. For example, you can play a sound whenever a task aborts. For more information, see Setting
Alerts.
5. Applications Manager can log status changes for tasks, Agents, and the Automation Engine. If you have the
DBA User Group, you can configure status logging options from the Task Events and Agent Events tabs of the
Settings window. If you do not have the DBA User Group, you will not see these tabs.
6. To save the settings for the current session and future sessions, click OK.
What Are User Options?
User Options are additional settings selected by your Applications Manager administrator. They control User
access to Applications Manager features such as the Hide feature in the Output window.

Setting Alerts
If the color change in the status bar is not a sufficient alert for your monitoring purposes, you can set additional
alerts for specific statuses. For example, you might have a sound or voice message play when a task aborts. Alerts
launch a program or script on the client machine while you are logged on. To set the alerts, use the Alerts tab on
the Settings window shown below.

Statuses
You can define alerts for the following statuses:
• Aborted task: when a task completes with a non-FINISHED status such as ABORTED
• Hold task: when a task goes into a HOLD status
• Agent trouble: when an Agent goes into a status that requires operator intervention such as a BUSY or
TROUBLE
• All clear: when all task/Agent statuses are changed so that tasks are eligible to run again
You can choose to trigger the alert when the first task or Agent displays the status, or every time a new task or
Agent displays the status.
Local Windows Programs
 Applications Manager 9.4.1

An alert runs a local Windows program that you specify in the field next to the alert category. You must enter a
command which includes the full path to the program file. In the image above, commands like the following are
used to play .wav files with the operating system's default player:

cmd /c="C:\Sounds\abort_task.wav"

You may want to create custom scripts to run as alerts.

Procedure
To set an alert:
1. Display the Settings window by opening the Options menu and choosing Settings.
2. Select the Alerts tab.
3. For each type of alert, enter a fully-pathed program name, or click the Select button and choose the program
name.
The program you choose must be an executable or Applications Manager will return an error message when the
task/Agent goes into the specified status.
4. To activate the alerts, click the Alerts on option.
5. Choose one of the frequency options:
• First time: The alert is executed the first time a task or Agent shows the indicated status. The alert will not
be executed again as long as that task or Agent remains in the indicated status. For example, if three tasks
abort at the same time, you will get only one alert.
• Every time: The alert is executed every time a task or Agent shows the indicated status. For example, if
three tasks abort at the same time, you will get three alerts.
6. To save the alert definitions, click OK.
Creating Notifications
Applications Manager Notifications send messages and output files, based on task status, to any Output Device
defined in Applications Manager.
Applications Manager can log status changes for tasks, Agents, and the Automation Engine. If you have the
DBA User Group, you can configure status logging options from the Task Events and Agent Events tabs of the
Settings window. If you do not have the DBA User Group, you will not see these tabs.

Viewing Operations Reports

Applications Manager comes with a set of Reports that provide information about the Applications Manager objects.
You can also import an extensive set of Applications Manager History Analysis Reports that allow you to review
how tasks were processed. Additionally, you can create your own custom Reports. A Report that audits schedule
changes is shown below. Additional Reports may be created if Users have the necessary User Group access.
 Applications Manager 9.4.1

You can view Reports for each of the operations windows and selector windows.

To view Reports for: Do this:

An object type Open that object's selector window and clickReports .

An operations window Open the operations window and choose the Report
type from the Reports menu.

This opens the Reports window and selects the Report type corresponding to the window you opened it from. In
the image below, the Reports button is selected on the Jobs Selector window, opening the Reports window with
the Jobs type highlighted.
To view Reports for another object type, select that object type from the Type box. If an object is not listed in the
Type box, there are no Reports for it. Once you select a Report, click the Show button.
 Applications Manager 9.4.1

Enabling Audit Reports

To run auditing Reports, your Applications Manager administrator must enable auditing for the Automation Engine.
Prompt Values
Some Reports require you to enter prompt values. If the Report you select requires prompt values, you must
respond to the prompts in the Report Parameters window shown below. Once prompt values are provided (if
necessary), Applications Manager displays the Report in its own window.

Changing the Lines per Page

 Applications Manager 9.4.1

You can specify the number of lines displayed on each page using the Lines per Page field. The new setting will
go into effect when you click the Redisplay button. Doing so will update the time and date in the Report header, but
not the data displayed in the Report.
Running Applications Manager History Analysis Reports
You can import Applications Manager History Analysis or AHA Reports. They include an AHA prefix designation in
their names. For example, the AHA-FINISHED_JOBS_BY_STATUS_HR Report returns completed tasks according
to status by hour. Data relating to AHA Reports is generated and loaded into Applications Manager by running the
CALC_HISTORY_STATISTICS Job.

Customizing Tables
Many of the Applications Manager windows display tables of information. In these windows, you can choose the
columns displayed and their order using Setup windows.

The tables that you can customize are listed below:

Menu Option Customizes

Backlog All views of the Backlog viewable from the Explorer

window.

History History on the Explorer window.

Output The Output window.

Agent Summary The Agent Summary on the Explorer window.

 Applications Manager 9.4.1

Menu Option Customizes

Queue Summary The Queue Summary on the Explorer window.

Process Flow Summary The Process Flow Summary on the Explorer window.

Status Summary The Status Summary on the Explorer window.

Task Output files The Output files tab on the Task Details window.

Agent Logs The Agent Logs window.

Gantt task summary The information displayed in the pop-up table when you
hover over a Job or Process Flow in the Backlog Gantt
view window and the Flow Diagram window.

Backlog task summary The information displayed in the pop-up table when you
hover over the Run ID column for tasks in the Backlog.

The steps for choosing columns and changing the column order are the same for all tables. To edit a table,
open the Options menu, select Tables, then select the table you want to edit. The Setup window for the Queue
Summary table is shown above.
The top of the window shows the table as it will be displayed in Applications Manager. The bottom of the window
displays a list of the columns that can be displayed.
Making Changes
The table below describes how to customize Applications Manager tables.

To: Do this:

Display a column Check the VISIBLE column.

All visible columns are brought to the top of the list.
Newly checked columns are added to the far right side
of the table. You can click the title of the column in the
top display and drag it to a new location.

Change the name of a column Edit the entry in the Name column.

Control the width of a column Enter a number of pixels in the MAX_WIDTH and
MIN_WIDTH columns. If you enter MIN_WIDTH
settings, its possible that some columns will be pushed
off the table. If this happens, select the Horizontal
scrolling option described below.

Format date columns Select a date format from the FORMAT column.

Control the margins within a column In the Column marginfield, enter a number of pixels to
be added to the left and right margins of the column.

Allow scrolling By default, tables do not scroll. As you add columns,

Applications Manager adjusts the width of the columns
so they are all displayed in the table.
If the tables become to narrow to read the contents,
you can select the Horizontal scrolling option. This
maintains the default width of the columns and displays
a scroll bar across the bottom of the table.

Change the order of the columns Select the title of a column in the top window and drag it
to a new location.
 Applications Manager 9.4.1

To: Do this:

Return the table to its last saved setting Click the Reset button at the bottom of the window.

Default Settings
Your Applications Manager administrator can set default settings for Applications Manager tables. If you customize
tables, the default settings are overridden.

Changing Status Colors

You can change the colors used to indicate statuses for tasks, Agents, and the Automation Engine in the Backlog
and History.
In the Backlog and History on the Explorer window, Applications Manager displays a task's status in the Status
column. To provide visual cues, Applications Manager uses colors for the statuses. For example, green is
RUNNING, yellow is HOLD, and red is ABORTED. If you wish, you can change the colors used for groups of
statuses.

Procedure
To change the color for a group of statuses:
1. From the Options menu, select Status colors.
 Applications Manager 9.4.1

Applications Manager displays the Status colors window shown above.

2. Select the status group you want to change and click Edit.
Applications Manager displays the color selection window shown above.
Statuses included in each group are listed below.

Group Statuses

Ready to run QUEUED

Time Dependent DATE PENDING

Resource Dependent SELF WAIT, QUEUE WAIT, CONDITN WAIT,

UNAVAILABLE, AGENT WAIT, PRED WAIT

Intermediate Completion STG SKIP, PW-SKIP, PW-DELETE

Hold HOLD PRED WT, HOLD

Staged STAGED HOLD, STG_PW HOLD, STAGED,

STAGED_PW

Running LAUNCHED, STARTING, RUNNING

Completion FINISHED, SkipCond, CANCELLED, DELETED

Error DB ERROR, RESUMED, STARTED, STOPPED,

ERRORS, EXPIRES, EXPIRED, IDLED,
TROUBLE, BUSY, CHECK LOG, INACTIVE, BAD
CONNECT,BAD MJN, BAD TYPE, BAD BATCH, BAD
LIBR, BAD LOGIN, HOST FAILURE, BAD QUEUE,
BAD DATE PRM, BAD SQL STMT, BAD MODULE,
BAD_AGENT, FILE_ERROR, START_ERROR,
START_FAILED, RECURSIVE, BAD CONDITN,
DIED, ABORTED, KILLED, TIMEDOUT, LAUNCH
ERROR

Intermediate Error DEAD, ABORTD, KILL, TIME-OUT, KILL1, KILLING,

LAUNCH ERR
3. Select a color and click OK.
Default Settings
Your Applications Manager administrator can set default values for status colors. If you customize status colors,
they override the default settings.

Viewing the About Applications Manager Window

Use the About Applications Manager window to view details about your Applications Manager build. This
information may be requested if you call Broadcom Support. When you select the About Applications Manager
menu item from the Help menu, Applications Manager displays the About Applications Manager window.
The About Applications Manager window includes:
• The Applications Manager version and build number
• Workstation Java VM information
• Server Java VM information
• Java VM free memory information
• The DNS name and IP address of the computer you are using
• The RMI host's DNS name and IP address
• The RMI host's port number
• The Oracle database version and details
To place the system information on your clipboard, click Copy.
 Applications Manager 9.4.1

To view copyrights for third party software used by Applications Manager, click Copyrights. Copyright information
also exists in the copyrights directory on the Applications Manager Automation Engine.
Java Garbage Collecting from the Applications Manager Client
You can do a Java garbage collection to free up heap memory that is no longer needed by clicking Java Garbage
Collection under the Debug menu on the About Applications Manager window. This will only send a hint to
Java, so it doesn’t force it to collect everything.
Setting Debug from the Applications Manager Client
You can turn on debug for the Applications Manager client, the RMI server, or Oracle trace by selecting options in
the Debug menu.

Opening the Applications Manager Client and Logging In

You must download the Applications Manager client from the URL set during the installation your Applications
Manager sent you . Before logging in the first time, you need to configure the client for the Automation Engine(s)
you will be logging into. Once configured, you open an executable .jar file. To log into the client, you must enter
your User name, password, and select an Automation Engine.
Downloading and Opening the Applications Manager Client
To download and open the Applications Manager client:
1. Open your browser and enter the URL set during the installation your Applications Manager sent you. The
screen shown below is displayed.
The default format for the URL is http://<Automation Engine IP address>:<Web Server port number>/
<Automation Engine name>/Intro.html.
For example, if the Automation Engine IP address is 200.2.2.123, the port number is 8080, and the
Automation Engine name is PROD1, the URL would look like the following:

http://200.2.2.123:8080/PROD1/Intro.html

The Applications Manager client requires a supported version of the Java Runtime Environment (JRE). For a
list of compatible Java versions, click the Compatibility Matrix link.
2. From this page, click the Download the Applications Manager Client link.
This downloads the Client.zip file.
3. Create a directory on your local PC for the client, for example, C:\AM_Client.
 Applications Manager 9.4.1

4. Move the Client.zip file to the directory you created and unzip the contents in that location.
5. Copy connections.properties.template to connections.properties.
6. Edit connections.properties. Replace {MASTER} with the name of your Applications Manager
Automation Engine and {URL} with the URL to your Applications Manager Automation Engine, such as,
http://127.0.0.1:8080/AMPROD.
For example, you might replace...

{MASTER}={URL}

With...

AMPROD=http://127.0.0.1:8080/AMPROD

To add connection information for additional clients, simply add additional lines in the same format.
7. Copy client.properties.template to client.properties.
8. Optionally, edit client.properties to set client properties.
Text from a sample client.properties file is shown below.

#localOptions=true
#debug=true
#logDir=log
#JAVA_HOME=C:/Program Files/Java/jdk-11
runOptions=-Xmx256m

The client.properties file includes the following settings:

• localOptions: When set to true, Applications Manager uses a local Options.properties file on your PC.
The local Options.properties file will be in a sub-directory for the client with the master's name. The local
Options.properties file will be download once. The advantage of using a local Options.properties file is
that you can specify settings for yourself without affecting other users. When set to false, commented out
(default), or otherwise not set to true, the Options.properties file on the Automation Engine machine is
used.
• debug: Allows you to turn on client debug by entering debug=true. When client debug is set, debug
information is written to the files in the log sub-directory or a different sub-directory is one is specified under
logDir.
To turn debug off, comment out debug=true in the client.properties file like the following.

#debug=true

It is also possible to set client debug from the About Applications Manager window once you are logged
into the client. However, it is advantageous to set it here, so that debug is on for the client start-up.
• logDir: Allows you to override the name of the sub-directory where client log files are written.
The client log sub-directory includes the following files:
• client.log: Includes all client standard and debug logging up until you click OK on the Logon window.
• <master or connection name>_client.log: Includes all client standard and debug logging for your
client session.
• JAVA_HOME: Allows you to use a different Java than your PC's default Java.
 Applications Manager 9.4.1

You must use either forward slashes (recommenced) or double backslashes in the path. This is the
standard for Java properties files.
To see your PC's default Java, open a command prompt and type java -version.
• runOptions: Used to increase the memory for your client. Don't make any changes to this setting unless
directed to by Applications Manager support.
• TheuserLanguageFiles: This setting is hidden in the client.properties file and in the documentation by
default. It allows you to specify a master name to use language translations on. When a master is specified,
there will be a drop-down with the languages, which are specified in the Options.properties file for the
master. We believe no one uses this desupported feature anymore.
9. Use RunClient.jar to start the Applications Manager client.
Applications Manager displays the Login window shown below.

Optionally, you may create a shortcut of RunClient.jar and place the shortcut on your desktop.
If the Logon window does not come up, open command window, navigate to the client directory, and enter
java -jar RunClient.jar to see the output. This information will help you or Applications Manager support
troubleshoot the problem.
When starting the local client by double clicking on RunClient.jar (or a shortcut to it) in version 9.3.1 or above,
if it fails to start the error will now be in the startClient.log file.
10. On the Logon window, specify your User, password, automation engine.
User names are not case sensitive, but passwords are.
If you do not know your User name and password, check with your Applications Manager administrator.
11. If the Language field is available, select your language.
Specifying languages for the client is a desupported feature. The Language field is only available in
Applications Manager systems where languages were translated in a previous version.
12. On the Logon window, specify the following:
• The default user name SQLOPER.
• The default password is s0pass, where "0" is zero.
13. To have Applications Manager remember your User name and Automation Engine, select the Remember
logon button.
14. To accept the entered information and log on to Applications Manager, click OK.
If you have a large number of output files or tasks in the Backlog, Applications Manager will display a message
alerting you that the display has been truncated.
When you log out of Applications Manager, the following settings are remembered the next time you log back
in:
• The size and position of Explorer and Backlog Gantt View windows.
• The size and position of the main Applications Manager client window.
• The content pane of the Explorer window (if open).
• Whether a saved Backlog/History Filter was selected.
Upgrading the Client
To upgrade to a new version of the client:
1. Download the new version of the client Client.zip from the URL
set during the installation
your Applications Manager sent you
.
2. Delete everything except the connections.properties and client.properties files from your client directory.
3. Put the files from the new version of the Client.zip file into your client directory.
Receiving RmiServer Error Broadcasts
If the Receive RmiServer Error Broadcasts User Option is assigned to your User, the RmiServer Errors window
might pop up with one or more errors when you log in.
 Applications Manager 9.4.1

When the Receive RmiServer Error Broadcasts User Option is assigned to a User, any RMI errors will be
displayed in a pop-up window as they occur. Additionally, if any RMI errors occurred since the last time the RMI
server was started, the last ten errors will be displayed in a pop-up window each time the User logs on.
If you have the DBA User Group, you can clear the RMI errors without stopping the RMI server by selecting Clear
RMI Errors from the View menu on the Applications Manager Desktop.
Re-Logging on to Applications Manager
There may be times when you want to log on to Applications Manager under a different user name or connect to
a different Automation Engine. To change your logon from the desktop, go to the File menu and select Re-Login.
You will have to re-enter your password when you re-log in, unless the Disable clearing of login passwords on
re-login Automation Engine option is checked.
Changing Your Password
You can change your password at any time. Your Applications Manager administrator can also set your password
to expire after a certain period of time.
To change your Applications Manager password go to the Options menu on the Applications Manager desktop and
click Change Password.
Accessing the Client Through a Firewall
If you will be accessing the Applications Manager client through a corporate firewall, you must open the appropriate
ports, and specify those ports in the Options.properties file on the host machine.
For details, see Configuring the Applications Manager Client.
For details, see the Installation Guide.

Requesting and Submitting Jobs and Process Flows

There may be times when you want to run tasks outside of a set schedule. You can submit individual Jobs and
Process Flows from the Requests window. We refer to these as "ad hoc" requests. After requesting and submitting
one or more Jobs/Process Flows, you can view their statuses from the Explorer window.
 Applications Manager 9.4.1

Requesting and Submitting Jobs and Process Flows

The ability to request Jobs and Process Flow on an ad hoc basis offers a useful way to request tasks that have not
been scheduled ahead of time.
When requesting Jobs and Process Flows, you use the following two windows:
• The Requests window shown in the image above is used to select one or more Jobs/Process Flows.
• The Submit window shown in the image below is used to complete prompts, select options, and submit the
requested Jobs and Process Flows to the Backlog.
When you request tasks, you can set the start date and time, Queue, designated Output Device, send option,
number of copies, and output function (LOG, PRINT, or STORE). You can also enter values to customize a Job or
Process Flow if prompts have been defined.
 Applications Manager 9.4.1

Checking Task Statuses

After submitting a Job or Process Flow, you can view its status in the Backlog and History. For information on the
Backlog and History, see chapter Monitoring and Managing Tasks in Explorer.
Viewing Output
After a Job executes, you can view and print output online using the File Viewer window. You can access the File
Viewer window from the Explorer, Backlog Gantt view, and Output windows. For information on viewing and
printing output, see chapter Viewing and Printing Output.
Re-Requesting Tasks from History
To re-request a task listed in the History pane of the Explorer window, right-click the entry and select the Request
option. Applications Manager lists the selected Job or Process Flow on a tab in the Submit window.
When you re-request a Process Flow component this way, it will run with the same prompt values as the selected
entry in History. All other settings, including alias name, conditions, predecessors, output settings, and Queues will
use the values set in the Job definition.
Requesting a Job or Process Flow from its Definition
 Applications Manager 9.4.1

You can also request a Job or Process Flow from it's definition. This opens the Submit window, like the Request
window does. This is beneficial for testing changes you make to the object.

Requesting Jobs and Process Flows

The Requests window offers a quick and easy way to request Jobs and Process Flows.

Procedure
To request one or more Jobs from the Requests window:
1. Open the Requests window shown above by doing one of the following:
• Open the Activities menu and select Requests.
• Select the Requests icon from the toolbar.
2. If appropriate, select an Application from the Application list box on the left side of the screen.
Applications specify a group of Jobs and Process Flows. The Application you select determines the Jobs and
Process Flows displayed in the table. Only the Applications and Jobs assigned to you via User Groups will be
displayed.
3. Select one or more Jobs from the list of Jobs and Process Flows on the right side of the screen. To select more
than one object, use Shift-Click or Ctrl-Click.
When selecting a Job/Process Flow, you can type the first few letters of its name in the Search field and
Applications Manager will find it. The Search field accepts valid regular expressions.
You can double-click to quickly request a single Job or Process Flow.
4. If the Requestor field is active, you can select the User that will be assigned to the Job/Process Flow.
You must have the Select Requestors User Option assigned to you by your Applications Manager administrator
to select a different User in this field.
5. To have the Requests window automatically close upon request, check the Close on Request box.
6. To request the Job(s), click Request.
Applications Manager opens the Submit window and displays the selected items as tabs. Each Job can
be viewed by selecting its tab. In the image below, three Jobs have been requested: JOB_REPORT,
MODULE_REPORT, and REPORT_BATCH.
 Applications Manager 9.4.1

If any Jobs or Process Flows you select have Agent Groups assigned to them with application Agents, you will
be prompted in a pop-up window to select which Agent you want to use to validate prompts. You will still be able
to select the Agent or Agent Group for these tasks to run on from the Submit window.
Next Step
After requesting one or more Jobs and/or Process Flows, the next step is to enter prompt values, select options,
and submit. For more information, see Submitting Jobs and Process Flows.

Submitting Jobs and Process Flows

After requesting Jobs and Process Flows, they are displayed in the Submit window shown below. You can enter
values for the prompts and options before you submit the Jobs and Process Flows.
 Applications Manager 9.4.1

Procedure
To respond to prompts and submit options:
1. Respond to the prompts in the Prompts box. Prompts are defined by an Applications Manager developer and
are specific to the Job or Process Flow. They are most often used to pass values to the program being run
by a Job. When a prompt includes a Select button as shown below, you can click it to select a single value or
multiple values from a list of options (depending on the Job/Process Flow definition).
Selecting values from lists helps to eliminate data entry errors. For information on selecting options from a list,
see Working in the Applications Manager Windows.
2. If the Send To option is active, select an Output Device from the drop-down list.
The Output Devices displayed in the list are determined by the Output Group assigned to the Job or Process
Flow. If the Send To option is not active, an Output Group was not assigned to the Job/Process Flow. You can
still run the Job/Process Flow and view output online, but the output will not be sent to an Output Device.
3. If the Send Option is active, select an option from the drop-down list.
The Send Option will be active if an output option is defined for the Output Device you select.
4. Select an output function from the Output Function drop-down box The output function determines how
output is handled. With any of these settings, the application output or report files and the system output files
are viewable from the Explorer window. There are three choices:
• LOG: Legacy setting that should not be used unless you need to use the Output window rather than the
Explorer window. For Jobs that have the output function set to LOG, Applications Manager loads all output
 Applications Manager 9.4.1

or report files in the Output window every time you log into the client. This can take several seconds or
minutes. If more than 500 files are loaded, an alert will be displayed. Therefore, if you are not using the
Output window (that is, you view output from History instead of the Output window), you should use the
STORE setting.
• PRINT: The output is printed according to the output settings specified on this tab.
• STORE: The output is not printed.
5. If you are printing and want more than one copy of the output generated by the task, enter a value in the
Copies field.
6. Select a Queue from the Queue list box
The Queue list box will be active only if you have been assigned the Select Queues For Requests User
Option by your Applications Manager administrator. If you have not been assigned this option, the Queue list
box will be read-only, and will list only the default Queue of the Job.
7. If you are requesting a Job that was assigned to an Agent Group (or a Process Flow assigned to a multi-
execution Agent Group), you will be able to select a specific Agent from the Agent drop-down list.
8. The Requestor field is read-only and shows the user name that is assigned to the task. This name will be
displayed in the Requestor columns in the Backlog and History.
9. To set a different start date and time, place the mouse cursor in the Start Date field and enter a new date or
time. Or, click the button to the right of the field to open a window where you can select the date and time.
If you set the date and time forward, the task status in the Backlog will be shown as DATE PENDING.
Components of a Process Flow in DATE PENDING status will show as STAGED or STAGED_PW status
(depending on the components' predecessor requirements). If you set the date or time to a time that has
already passed, the task will be eligible to run immediately.
You can pre-date the start date of this Job or Process Flow to meet the predecessor requirements for tasks
waiting in the Backlog from a previous virtual day.
10. If you want the task to go into a HOLD status when it is submitted to the Backlog, you can select the Hold
option. The task will stay in the Backlog with a HOLD status and not run until you reset it.
11. If documentation has been created for the Job, you can view it by clicking the Documentation button.
12. When you have entered the prompt values and set the options, you are ready to click one of the following to
submit the Job or Process Flow:
• To automatically close the Submit window after it the Job is submitted, click the Submit & Close button.
• To keep the Submit window open, click the Submit button. After you submit the Job or Process Flow this
way, Applications Manager displays a message in the status bar (see below). If you submit a large Process
Flow the message will read, 'Task submission in progress: run_id = <run ID number>' until all components
of the Process Flow have been placed into the Backlog. The Close button will be grayed out until the task
is in the Backlog. Once the task is in the Backlog the message will read, 'Task was Successfully submitted
run_id = <run ID number>'.
 Applications Manager 9.4.1

Removing Tabs for Jobs and Process Flows from the Submit Window
If there is more than one tab in the Submit window, you can remove the tab by selecting it and clicking Close Tab.
To close the Submit window and all tabs, click Close.
Invalid Prompts
After you click Submit, Applications Manager checks the prompt values. If the values you assigned to prompts are
invalid, Applications Manager will display an error message. You can correct the values and then submit the Job or
Process Flow.
Adding a Suffix to a Job or Process Flow Name So Predecessor Links Are Not Satisfied
To add a suffix to a Job or Process Flow name, enter the suffix in the Task Name Suffix field. The Job or Process
Flow will run with an underscore followed by the suffix at the end of its name. This will prevent the request from
satisfying any predecessors, since the name is changed.
The Task Name Suffix field will only be available if you have been assigned the Set Task Name Suffixes User
Option by your Applications Manager administrator.

Viewing and Printing Output

One of the most unique features of Applications Manager is its ability to capture output from tasks and make it
available for printing and viewing online. Online viewing gives you immediate access to report s as soon as they
have been generated. Applications Manager captures both the log file of the task and any output generated by the
 Applications Manager 9.4.1

task. The output generated by the task may exist in the out directory where the Automation Engine is installed, or
in a directory on another server associated with the application. Where output is registered is determined by the
Program Type script associated with the Job.

After you submit a task and it executes, you can view the output as plain text, HTML, or rich text format using the
File Viewer window shown above. You can also use an alternate viewer using file associations. For information
on setting file associations, see Opening Output Files with Other Applications . Output can be printed to a local or
system Output Device.
Opening the File Viewer Window
You can access the File Viewer window from:
• The Explorer window.
• The Output window.
The Explorer window is used to monitor and manage Applications Manager tasks, as well as Agents and Queues.
To open the File Viewer window from the Explorer window, right-click a task in the Backlog or History and select
Output from the pop-up menu. For more information on viewing output from the Explorer window, see Task Output
Files: Viewing.
The Output window provides access to task output for Users who have not been given access to the Explorer
window. To open the File Viewer window from the Output window, select a task and click the View button. For
more information on viewing output from the Output window, see Working with the Output Window .
Querying for Tasks
 Applications Manager 9.4.1

You can query History in the Explorer window and you can query the Output window. You can search for specific
tasks by criteria such as Job name, Process Flow, Agent, and requestor. For more information on querying, see
topics Querying for Tasks in History and Querying the Output Window .
Viewing Output in Other Applications
After a task has completed, you can view the output in the File Viewer window as shown above. You can
also associate types of files with other viewers. For example, if you are generating an .xls file, you can have
Applications Manager automatically launch Microsoft Excel as the viewer. To do this, you must specify the
association in the File Association window. For information on setting file associations, see Opening Output Files
with Other Applications .
Printing Output
After viewing a report, you can preview the printed output and print it to a local Windows printer or to an
Applications Manager Output Device. These options are available from the File Viewer window's File menu and
from the icons in the File Viewer and Output windows. For more information on printing output, see Printing,
FTPing, and Emailing Output Files.

Working with the Output Window

The Output window only exists for legacy purposes. We do not suggest new users use it for any purpose. The
Output window shown below provides access to task output for users that have not been given access to the
Explorer window. By default, only tasks whose Output function was set to LOG will be displayed in the Output
window. These tasks have a logged status. You can see printed, stored, or viewed tasks by running a query and
searching for tasks with one or more of these statuses.

Opening the Output Window

Open the Output window by doing one of the following:
• Open the Activities menu and select Output.
• Select the Output icon from the toolbar.
Output Restricted to User
By default, only the tasks you have submitted will be displayed in the Output window unless the View Other
Users' Output option was assigned to you by your Applications Manager administrator. With this option set, you
will have access to all outputs for the Jobs you have been assigned access to regardless of the User that submitted
the Job. If View SYSOUT Device Output Files and View Other Users' Output are not assigned to your User,
Applications Manager restricts output that is assigned to the SYSOUT Output Device on this window.
Output and User Groups
 Applications Manager 9.4.1

When you are setting up User Groups, consider setting up a User Group for end-users that includes access to the
Requests and the Output windows only. This lets end-users submit, view, and print their specific task requests.
Working with the Output Window
The table below describes the available actions on the Output window.

To: Do this:

View output Select a task and click the View button. Applications
Manager displays the output in the File Viewer window.
For information on using the File Viewer window, see
Viewing Output Files with the File Viewer.

Query for specific tasks Click Query on the Output window. You can query
for a specific task by a wide range of criteria such as
Job name, Process Flow name, requestor, and output
status. For more information on querying the Output
window , see Querying the Output Window .

Hide or unhide tasks Select one or more files and click the Hide button. To
select multiple adjacent files, use Shift+click. To select
multiple non-adjacent files, use Ctrl-Click. Hiding output
changes the status of the selected files to STORED and
removes the listing from the viewable list. To hide all
listings in this window, request the OLDPRTS Job.
To display hidden files, you must use the Query
function and query for the STORE status. If after
querying, you select a file and click Hide, its output
function will be changed to LOG.
If the Hide Files on the Output Window option was
not assigned to you by your Applications Manager
administrator, you will not be able to use the Hide
button.

Refresh the display Click the Refresh button. When you first open the
Applications Manager client, tasks that have completed
with a LOG status will be available for viewing without
running a query on the Output window. If other tasks
complete while you have a client session open, they
will not automatically be added to the Output window.
Refresh the display to see them.

Print output Select a task and click the Print button or one of the
Print icons. For more information on printing output, see
Printing, FTPing, and Emailing Output Files.

Customizing Table Columns

You can customize many tables in Applications Manager including the table in the Output window. When
customizing tables, you determine which columns are listed, what each column is named, and how each column is
displayed.
Your Applications Manager administrator can set default values for tables. Therefore, the columns in the Output
window may be different from what is described above. For more information, see Customizing Tables .

Querying the Output Window

If you are looking for a specific task and the number of tasks listed in the Output window is overwhelming, or you
wish to view output from tasks which are not listed by default, you can run a query on the Output window.
 Applications Manager 9.4.1

Procedure
To perform an output query:
1. Click the Query button on the Output window.
Applications Manager displays the Output query window shown above.
2. Select search criteria for your query.
You can use any combination of query criteria available in the Output query window.
The Output query window fields are described below.
• Jobs
Searches for any task assigned to the specified Job(s), including tasks that ran the Job under an alias name.
To query for a task run under an alias, enter the alias name.
• Process Flows
Searches for tasks that are part of the Process Flow(s). The Process Flows themselves are not returned.
• Agents
Searches for any task run on the specified Agent(s).
• Output Devices
Searches for any task assigned to the specified Output Device(s).
• Requestors
Searches for any task run by the specified requestor(s).
• Output Function
 Applications Manager 9.4.1

Searches for tasks based on the output function set for the Job at run-time. There are three statuses:
• LOG: The output is available for printing, but has not been printed. Outputs with this status appear on the
Output window list by default.
• PRINT: Same as LOG, but output is sent to Output Devices as well.
• STORE: You must query to see output files with this status. System output files are typically stored.
• From start time/To start time
These fields accept date/time information. If the Current day option is selected, the From start time and To
start time fields will be inactive.
• Run ID
This field references the unique number (format: 1320.00) assigned to each task by Applications Manager.
When using this field, include the decimal value where appropriate. Decimal values at the end of Run IDs
indicate that tasks have been restarted. Every task has .01 added to its Run ID each time it is restarted.
• Current day
The default is to query by the current virtual day. If you save a query with this option checked, it will be
applied each time you run the saved query.
The date and time of the current day are saved as an offset from the current time. That means that if you
save a query for tasks run in the last two days, it will always run a query for the tasks in the last two days.
There is no way to save a query from a specific date. If you uncheck this option, the From start time and To
start time fields become active. You then can enter specific dates and times for the query.
To query by one or more objects, enter values in each object's field by doing one or both of the following:
• Type in names of the objects separated by commas.
• Select from a list of objects by clicking on the object icon at the end of the field.
3. You may select a default sort order for the query by selecting a Sort option.
The sort order can be overridden from the Output window by selecting a different column name.
4. You may also optionally save this output query to use later by entering a name in the Filter name drop-down
box The output query will be saved when you click OK.
Saved Output queries can be recalled from the Filter name drop-down box for History queries, Output queries,
and filters of the Backlog and History.
5. Click OK.
Applications Manager displays a small animated window as it processes the query. Once the query is
processed, Applications Manager displays the results in the Output window.
Using the Object Assignment Windows
When you click on an icon at the end of one of the applicable fields, Applications Manager displays the object
assignment window where you can pick one or more objects to use in an output query. The windows will list
only the objects to which you have User Group access. Use the arrow buttons to move objects between the
Unassigned and Assigned tables. For more information on assigning objects, see Working in the Applications
Manager Windows.
 Applications Manager 9.4.1

Use the Other filters field to enter text-based filters.

• You can enter several letters, and all objects beginning with those letters will be included.
• You can use wildcards in the text. You can use the _ wildcard to represent a single character, and the %
wildcard to represent an unlimited number of characters.
• You can include negative filters to exclude tasks from the search using the ! character. For example, entering !
AW% will exclude tasks with the letters AW together in their name.
Any text entered in the Other filters field will be included in the appropriate field on the Select filters window.
Use the Search field to query the Unassigned table. You can apply the search criteria to the Assigned column as
well by unselecting the Show all assigned option.
Viewing Query Results
When you click OK in the Output query window, Applications Manager runs the search and displays the queried
results. The Apply Query checkbox will be checked as shown below. To clear the query, uncheck the Apply Query
box. You can view the queried results again by rechecking the Apply Query box. To apply a saved output query,
select it from the drop-down box
 Applications Manager 9.4.1

Viewing Output Files with the File Viewer

After a task executes, you can view its output online from the Applications Manager client. This means you can
view a report as soon as it is available rather than waiting for printed output to be distributed. Online viewing also is
useful if you are trying to debug a new program or if the output is such that you do not need a hard copy.
 Applications Manager 9.4.1

You can enter page and line numbers for viewing, and bookmark pages. Output is automatically displayed in one of
three formats: plain text, HTML, or rich text format.
You can use the File Viewer window shown above or an alternate viewer. For information on viewing output with
alternate viewers, see Opening Output Files with Other Applications .
Viewing Output Files
To view output, open the File Viewer window by doing one of the following:
• From the Explorer window, right-click a task in the Backlog or History and select Output from the pop-up menu.
For more information on accessing the File Viewer window from Explorer, see Task Output Files: Viewing.
• From the Output window, select a task and click the View button. For more information on accessing the File
Viewer window from the Output window, see Working with the Output Window .
From the File Viewer window, you can:
• Copy text to the clipboard with Ctrl-C.
• Go to the start or end of the output file using the Home and End keys when the output text is in focus.
• Scroll through the output by using the horizontal and vertical scroll bars.
• Close the window by pressing the Esc key.
Printing, FTPing, and Emailing Output Files
You can print, FTP, or email output from the File Viewer window using the print icons or from the Print menu on
those windows. For more information, see Printing, FTPing, and Emailing Output Files.
 Applications Manager 9.4.1

Viewing by Page and Line Numbers

You can jump to a specific page and/or line number by entering them into the Page and LineNo fields at the top of
the window and clicking the corresponding Go To button or pressing Enter.
Finding Specific Text
To find specific text in the output file:
1. On the File Viewer window, go to the Options menu and select Find.
Applications Manager displays the Find window shown below.

2. Enter the text you want to find and click Find Next.
Check the Match Case checkbox for case sensitive searches. Applications Manager searches run from the
current location to the end of the file.
Bookmarking Pages
As you view a file, you can bookmark pages for printing by selecting the Mark Page button. Your marked page
numbers will display in the Pages box located at the bottom of the screen. When you print the output, only the
marked pages will be printed.
Changing Output Formats and Text Size
Applications Manager automatically selects HTML or rich text format styles based on each file's extension (.htm,
.html, .rtf). Other files default to plain text view. When using the plain text view, you can adjust the size of the text
used in the display by selecting a value from the Size list box at the bottom of the viewer. This changes the size
of the text in the viewer, but it does not impact the size of the text used when the report is printed. Output can be
viewed with an alternate viewer if a file association has been defined. For information on setting file associations,
see Opening Output Files with Other Applications .
Viewing the End of Files
To view the end of a text file, go to the Options menu on File Viewer window and select Tail. The tailing option
enables operators to observe the most recent end of file every 10 seconds by showing the report as it is being
printed to standard output. Use this function, similar to the UNIX tail -f <filename> command, when trying to
diagnose problems.

Printing, FTPing, and Emailing Output Files

You can print, FTP, or email output from the Output Files tab of the Task Details window, the File Viewer window,
or the Output window using the print icons shown below or from the Print menu on each window.

Printing Output Files to an OS Printer

To print the output to an OS printer:
1. From the File Viewer window, go to the Print menu and select Print, or click the Print icon.
Applications Manager opens a Print window.
2. Select the options and click OK.
If you have bookmarked one or more pages using the Mark Page button, Applications Manager will only print
the marked pages.
Printing to an Applications Manager Output Device
To print the output to any Output Device defined in Applications Manager:
 Applications Manager 9.4.1

1. From the File Viewer, go to the Print menu and select Send To, or click the Send To icon.

Applications Manager displays the Choose an Output Device window shown above.
2. Select an Output Device, copies, and output option and click OK.
Applications Manager prints to the Output Device you selected.
If you have bookmarked one or more pages using the Mark Page button, Applications Manager will only print
the marked pages.
To use the system print option, you must have User Group access to the Output Device you wish to print to and at
least one Output Group it is assigned to. If you do not think you have the necessary User Group access, see your
Applications Manager administrator.
Previewing a Print Task
To preview a print task, go to the File menu and select Print Preview, or click the Print Preview icon.
FTPing an Output File
You can send an output file to your client machine or a network location using the FTP function. To FTP a file:
1. From the Actions menu, select FTP or click the FTP icon.
 Applications Manager 9.4.1

Applications Manager displays the FTP window shown above.

2. Select the directory where you want the file placed.
3. Enter the name you want assigned to the file.
4. To initiate the transfer, click Save.
You cannot FTP files if the FTP Output Files option was not assigned to you by your Applications Manager
administrator.
Emailing an Output File
You can email output files without having to define an email Output Device. To email output files to one or more
addressees, go to the Print menu and select Email, or click the Email icon. Applications Manager opens an Email
window shown below.
 Applications Manager 9.4.1

Separate multiple email addresses with a space or semicolon. To select from emails assigned to Users, click the
Select button. Applications Manager opens a window where you can select the email addresses. You can decide
whether to add the output file as an attachment and include additional text using the box at the bottom of the
screen.
You also have the option to send the output file as an attachment, include it in the message body, attach it as a
PDF file, or include it in an attached zip file.
In order to send emails, you must specify email settings for the Applications Manager Automation Engine/Local
Agent.

Opening Output Files with Other Applications

There may be times that you want to view output files in a different application rather than in the Applications
ManagerFile Viewer window. To do this you define a file association. You might want to open files in another
application if the files are too large to view with the File Viewer window, or if the file includes formatting that only
a specific application will recognize. For example, if a report has a .xls extension, you can associate the file
with Microsoft Excel. From the associated application, you can save the output file to your PC. You define file
associations using the File Association window shown below.
 Applications Manager 9.4.1

After you create a file association, files with corresponding names will always, sometimes, or never open with
the associated application when you view the output from the Applications Manager client, depending on the file
association definition. You will also have the option to open any output file with the application you created the file
association for.
The file association(s) you create are associated with your User on your PC. They are not global settings unless
you share file associations for all Users as descried in Sharing File Associations with All Applications Manager
Users.
Adding File Associations
To add an output file association:
1. On the desktop, go to the Options menu and select File Associations.
Applications Manager opens the File Association window.
2. Enter a file pattern in the Pattern field.
The most common pattern for file associations are file extensions (for example .xls).
The Pattern field accepts valid regular expressions. Note that regular expressions are case sensitive.
3. In the Application field, type the name of the executable file for the Application you wish to associate with the
file type, or use the ... button to browse for it on your PC.
4. Select an option from the Use field.

To: Select:

Always open file type in the associated file viewer Always

Prompt before opening the file in the associated file Ask

viewer

Never use the associated file viewer or temporarily Never

disable the association
5. Click Add.
Applications Manager displays the file association in the table at the top of the screen.
6. When you are finished adding file associations, click OK to save them.
Opening Any Output File with a File Association's Application
You can manually open any output file from the Applications Manager client by selecting the Open With icon from
the Output Files tab of the Task Details window or the Output window. In the image below, the Open With icon
 Applications Manager 9.4.1

has been selected, and the Select Program window is open. From the Select Program window, you can select
the application you want to use to view the selected output file.

Sharing File Associations with All Applications Manager Users

If all Users that log into an Automation Engine need to use the same file associations, you can point them to a
common file named fileassoc.properties. File associations for individual Users are stored in the following file:

C:\Documents and Settings\<user name>\fileassoc.properties

To assign a common file to all Users, do the following:

1. Add the following line to the Applications Manager Automation Engine Options.properties file, where N:/
Automic/ is a shared directory and fileassoc.properties is the name of the file:

FileAssociations=N:/Automic/fileassoc.properties

You can use mapped drives or UNC paths.

For example:

FileAssociations=//rs62/ndrive/Automic/fileassoc.properties

Also, / should be used instead of \. Using backslashes will prevent properties from being saved.
The location for the Options.properties file is:
 Applications Manager 9.4.1

UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

2. Log into the Applications Manager client and set up a file association.
Applications Manager will create the file you specified in step 1 in the directory you specified and update it with
the file association information. The file association will now be globally changed for all Users that have access
to the drive you specified.

Monitoring and Managing Tasks in Explorer

From the Explorer window, you can monitor and manage Queues, Agents, and tasks. You can check the status
of Queues, change Queue settings, and assign Queues to Thread Schedules to control the number of tasks the
Queue can process. You can check Agent status, and start, stop, idle, or resume Agents. You can check the
statuses of tasks, restarting or killing the tasks if necessary. A sample Explorer screen displaying the Backlog and
History is shown below.
 Applications Manager 9.4.1

The Backlog and History

Two main parts of the Explorer window that allow you to monitor and manage tasks are the Backlog and History.
The Backlog is a list of tasks that:
• Are waiting to run.
• Are running.
• Have run and failed, and have stayed in the Backlog for operator intervention.
When a task leaves the Backlog, Applications Manager writes a record for it in History. History is an audit trail of all
failed and completed tasks. For more information on the Backlog and History, see topics Working with the Backlog
and Working with History.
Quick Searches for Tasks in the Backlog
You can type the first few letters of an task from the Backlog's name in the Search field, and Applications Manager
will find it. The Search field accepts valid UNIX regular expressions. For example, to search for all tasks starting
with the letters A and T, you would enter [at] in the Search field.
Reading the Status Bar
The status bar is displayed across the bottom of the Explorer window. Its color alerts you to the status of the
Applications Manager Automation Engine, Agents, and tasks running in the Backlog. When the Explorer window
 Applications Manager 9.4.1

is minimized, the button on the taskbar uses the same color scheme. For more information, see Monitoring with the
Status Bar and Object Icons.
Customizing Explorer Tables
You can choose the columns you want displayed in the Explorer window and customize their order and names. For
more information, see Customizing Tables .
Viewing Output Files and Task Details
You can view output files and other task details for any task in the Backlog or History. You view the task details for
a task by right-clicking it and selecting an option from the pop-up menu. For more information, see Viewing and
Editing Task Details .
Staging Tasks in the Backlog
Staging tasks in the Backlog allows you to edit task details before the tasks are scheduled to run. For more
information, see chapter Staging Tasks in the Backlog.
Monitoring and Managing Queues and Agents
Queues control the flow of tasks. All tasks must pass through a Applications Manager Queue to be executed.
Agents are instances of Applications Manager; an Agent is installed on each machine where tasks are executed.
An Agent can be an Automation Engine's Local Agent, or a Remote Agent. The Automation Engine is also listed
along with the Agents in the Explorer window. You monitor and manage Agents and Queues from the Explorer
window. For more information, see chapter Working with Agents and Queues.
Monitoring and Managing Tasks in the Gantt View
You can monitor and manage tasks in the Backlog using the Gantt View. For information on using the Gantt View,
see chapter Monitoring and Managing Tasks with the Gantt View.

Using the Explorer Window

Use Explorer to monitor and manage the status of your Agents, Queues, and tasks running in the Backlog, and to
focus the display of tasks in the Backlog. You can preview and print the object tree, Backlog, and History.
 Applications Manager 9.4.1

Opening the Explorer Window

Open the Explorer window by doing one of the following:
• Open the Activities menu and select Explorer.
• Select the Explorer icon from the toolbar.
Three Adjustable Panes
The Explorer window includes the following three panes:
1. The navigation pane on the left side of the screen provides a tree structure with selectable object icons.
2. The content pane on the top right side of the screen displays information based on your selection in the
navigation pane. It can show the Backlog (tasks waiting to be processed), a summary of objects selected in the
object tree, an Application summary, an Agent summary, or a Queue summary.
3. The History pane on the bottom right side of the screen displays records on how tasks ran. The tasks displayed
do not depend on your selection in the navigation pane.
Each of the panes can be resized by dragging the splitter bars, or clicking the splitter bar arrows.
Numbers to the right of the label for the Backlog and History indicate the number of rows currently displayed in
each. Every row is counted regardless of whether it represents a Job, Process Flow, or historical record. Some
tasks may include multiple records in History. For example, a task that aborts and is reset will include two History
records.
 Applications Manager 9.4.1

Explorer Terms
The following Explorer terms are used in this guide:
• Object tree: The graphical model displayed on the left pane of the Explorer window.
• Object icons: The icons used in the object tree to represent objects such as tasks, Process Flows, and
Queues.
• Object keys: The icons to the left of the expandable objects in the object tree. You can click the object keys to
show and hide objects in the tree.
Printing the Object Tree or a Table
You can preview and/or print the object tree, and the Backlog and History tables by selecting the appropriate
options from the File menu. The image below shows the print preview screen for a task in the Backlog in an
ABORTED status.

Working with the Backlog

Clicking the Backlog object tree icon displays running tasks, aborted tasks, and tasks that have failed and remained
in the Backlog for operator intervention.Two main parts of the Explorer window that allow you to monitor and
manage tasks are the Backlog and History.
 Applications Manager 9.4.1

Numbers to the right of the label for the Backlog and History indicate the number of rows currently displayed in
each. Every row is counted regardless of whether it represents a Job, Process Flow, or historical record. The
Backlog is a list of tasks that:
• Are waiting to run.
• Are running.
• Have run and failed, and have stayed in the Backlog for operator intervention.
To view all tasks in the Backlog in the content pane on the top right side of the screen, click the Backlog icon in the
object tree. In the image above, one task is running in the Backlog, some tasks are waiting in a PRED WAIT status,
and one task has aborted.
Whether a task remains in the Backlog when it fails is determined by the Stay in queue on abort setting in its Job
definition.
Tasks sometimes fail by aborting, timing out, being killed, etc. When a task fails, a record is written to History under
the current run ID number. If a failed task remains in the Backlog, its run ID is incremented by .01.
For example, in the image above, a task with the run ID 73016 aborted and remained in the Backlog. A record of
the task aborting is written to History, and the task remains in the Backlog with the run ID 73016.01.
From the Backlog, you can:
• Take actions on tasks (see Taking Actions on Tasks in the Backlog).
 Applications Manager 9.4.1

• View and edit task details (see Viewing and Editing Task Details ).
When a task leaves the Backlog, Applications Manager writes a record for it in History.

Working with History

History is an audit trail of completed and failed tasks displayed on the bottom of the Explorer window. Two main
parts of the Explorer window that allow you to monitor and manage tasks are the Backlog and History.

Numbers to the right of the label for the Backlog and History indicate the number of rows currently displayed in
each. Every row is counted regardless of whether it represents a Job, Process Flow, or historical record. Some
tasks may include multiple records in History. For example, a task that aborts and is reset will include two History
records.
History is an audit trail that includes records for:
• All completed tasks and occurrences of task failure(s).
• RMI servers or Agents being started, stopped, or having errors.
• The AgentService processes being stopped.
How long task history records are archived in the Applications Manager database is determined by the prompt
setting for the HISTORY_PURGE Job, which is part of the SYSTEM Process Flow. The default value is 60 days.
Your Applications Manager administrator is responsible for setting this value.
 Applications Manager 9.4.1

The Explorer window includes a partial view of History in its lower right pane.
The amount of History displayed when any User logs in to the client is determined by the HistoryRetentionTime
setting in the Options.properties file.
How long records are displayed in the History pane while a User is logged into an Applications Manager session is
determined by:
• Your History Display Minutes desktop setting. For more information, see Editing General Desktop and ToolBar
Settings.
• Whether you have a History query activated. For more information, see Querying for Tasks in History.
From History, you can:
• Unsatisfy tasks as predecessors (see Unsatisfying Tasks as External Predecessors in History).
• View task details (see Viewing and Editing Task Details).
• Add comments (see Task Comments: Adding and Viewing).
• View History Gantt Views (see Viewing History in a Gantt Chart).
• Re-request tasks as described below.
Re-Requesting Tasks from History
You can now re-request a single task listed in the History pane of the Explorer window. To do so, right-click the
entry and select the Request option. Applications Manager lists the selected Job or Process Flow on a tab on the
Submit window.
When you re-request Process Flow components this way, they will run with the same prompt values as the selected
entry in History. All other settings, including alias name, conditions, predecessors, output settings, and Queues will
use the settings in the Job definition.

Backlog and History Column Descriptions

The default columns in the Backlog and History are described below. You can customize many tables in
Applications Manager including the tables in the Backlog and History.
A sample Explorer window showing the Backlog and History is displayed below.
 Applications Manager 9.4.1

The default columns in the Backlog and History are described below. Columns unique to either the Backlog or
History are noted.
• Queue
The Queue the task is running on, will run on, or has run on.
• Run ID
The unique identification number Applications Manager assigned to the task.
Decimal values at the end of Run IDs indicate the number of times a task has either been killed or has aborted
and stayed in the Backlog. Each time a task is killed or aborts and stays in the Backlog, .01 is added to the
task's Run ID, and a record is added to History using the task's previous run ID.
• C
Uses a Y to identify tasks that include comments.
• D
Uses a Y to identify tasks that include documentation.
• Task Name
The name or alias, if defined, of the task.
• Start Date
 Applications Manager 9.4.1

The date the task started executing or is scheduled to start executing.

• Started
Displayed in the Backlog. The time the task is scheduled to start executing. After a task begins executing, the
time it started.
• Finished
Displayed in History. The time the task finished executing.
• Elapsed
The elapsed time the task ran.
• Status
The current status of the task. For a list of status values, see Task Status Values.
For status detail information that tells you why a task is in a particular status, rest the mouse pointer over the
Run ID column for the task and view the Status Detail information in the Backlog Task Summary pop-up table.
• Agent
The Agent or Agent Group where the task will execute (Backlog), or was executed (History). Process Flows
with 'No Selection' set in their Default Agent field will be assigned to the APPWORX_AGENTS Agent Group,
an Agent Group containing all Agents. The Process Flow itself does not run a program or script; only its
components do.
• Requestor
The person that submitted the task or the User entered as the requestor of the ad hoc request or schedule. If
nothing is displayed, a Requestor was not specified for a scheduled task.
• Parent
The Process Flow that contained the component. If the task is not a Process Flow component, this field will be
blank.
Viewing and Customizing Tables and Backlog Task Summaries
You can customize many tables in Applications Manager including the tables in the Backlog and History. When you
are working in the Backlog, a pop-up table is displayed when you hover over the Run ID column for a task. These
pop-up tables are called Backlog Task Summaries, and you can also customize them. When customizing tables,
you determine which columns are listed, what each column is named, and how each column is displayed.
 Applications Manager 9.4.1

Your Applications Manager administrator can set default values for tables. Therefore, the columns in the Backlog
and History may be different from what is described above. For more information, see Customizing Tables.

Focusing the Backlog Display with Explorer

Using Explorer, you can limit the tasks listed in the Backlog by selecting an icon from the object tree. You can view
a Process Flow Summary listing all Process Flows with one or more tasks in the Backlog by selecting the Process
Flows icon. An example Explorer screen displaying a Process Flow Summary is shown below.
 Applications Manager 9.4.1

The icon you select in the object tree determines the tasks listed in the Backlog.

To list: Select this icon:

All tasks in the Backlog Backlog

Tasks submitted using the Requests window Ad Hoc

Tasks assigned to a particular Agent The Agent

Tasks in an Agent Group The Agent Group

Tasks assigned to a particular Queue The Queue

Tasks assigned to a particular Queue The Application

Tasks and history records belonging to a particular The Process Flow

Process Flow

Tasks with a particular task status (WAITING, The status

RUNNING, ABORTED, or HOLD)

Tasks by Agent on a particular machine The machine and Agent

Sorting the Tasks in the Backlog by Status

You can click on the Status column header in the Backlog to display three different sort orders: ascending,
descending, and severity of status. When you sort tasks by severity of status, Applications Manager lists the most
severe task statuses first.
Customizing Tables
You can customize many tables in Applications Manager. When customizing tables, you determine:
• Which columns are listed.
• What each column is named.
• How each column is displayed.
Your Applications Manager administrator can set default values for tables. Therefore, the columns displayed in
Explorer may be different from what is shown here. For more information, see Customizing Tables.
Limiting the View of Tasks in the Backlog
 Applications Manager 9.4.1

To limit the view of tasks in the Backlog by object:

1. If necessary, click the icon's key to display the child objects. To view tasks in a Process Flow, you may need to
open several icon keys.

2. Select an object from the list of icons.

Applications Manager displays the list of tasks belonging to that object in the upper right pane as shown below.
 Applications Manager 9.4.1

Monitoring with the Status Bar and Object Icons

The status bar shown below is displayed across the bottom of the Explorer window. Its color alerts you to the
status of the Applications Manager Automation Engine, Agents, and tasks running in the Backlog. When the
Explorer window is minimized, the button on the taskbar uses the same color scheme.

The status bar reflects the most severe status in the system. The status bar colors and descriptions are described
below.

Color Description

Green All tasks, Automation Engines, and Agents are running

satisfactorily.

Yellow One or more tasks are on hold. If there are aborted

tasks and tasks on hold, the aborted tasks take
precedence and the status bar will be red.

Red One or more tasks have aborted, or otherwise

not completed with a status of FINISHED. Or an
Automation Engine or Agent has a BUSY or TROUBLE
status.

For a description of the Automation Engine/Agent status values, see Automation Engine/Agent Status Values . For
a description of the task status values, see Task Status Values .
The status bar displays the time that the Explorer window was last refreshed. You can manually refresh by
entering Ctrl-R or by clicking the status bar on the Explorer window. The Explorer window is automatically
refreshed based on the Explorer Refresh Seconds desktop setting. For information on editing desktop settings, see
Editing General Desktop and ToolBar Settings.
The current date and time of the database are displayed to the right of the status bar.
Viewing Components in a Process Flow
Process Flow components in the Explorer tree are listed based on the execution order of each tasks' predecessors.
When you select a Process Flow in the Explorer tree, those same components are displayed in the top right
Explorer pane according to your Backlog search criteria (by default this is based on task status). To view the
structure of a Process Flow, right-click and select Flow Diagram.
Managing Task Statuses with the Object Icons
The Explorer icons in the object tree alert you to task status and give you a quick method for finding aborted/on
hold tasks.
For example, PROCESS FLOW_1 is in the Backlog. PROCESS FLOW_1 includes four Process Flow components.
The first three icons represent Process Flows that ran successfully. When the fourth Process Flow ran, a task
aborted, leading to the sequence of events below.
 Applications Manager 9.4.1

1. When the task aborted, the status bar turned red to alert the user Pat Brown.
2. Pat opened the Explorer window and could see by the red X indicator on the Process Flows icon that one or
more tasks in a Process Flow had aborted.

Pat could have selected the Backlog, Ad Hoc, or Status icons to find the aborted task, but chose the Process
Flow option out of personal preference.
3. Next, Pat clicked the Process Flows icon key to view a list of running components.

The icon for PROCESS FLOW_1 had a red X indicator, so Pat knew that this Process Flow, or a Process Flow
nested therein, contained an aborted task.
4. Pat clicked the PROCESS FLOW_1 icon key to view the list of tasks belonging to PROCESS FLOW_1.
Pat could see that three Process Flows had finished successfully because the Process Flow icons were gray,
and that a task had aborted in the other Process Flow (because the Process Flow icon had a red X indicator).
 Applications Manager 9.4.1

Pat clicked the PROJECTED_NOV icon key to view the components in that Process Flow.
Pat could see by the red X symbol as the second task's icon showing that it aborted. A second listing for the
task, an orange icon with a circle and a diagonal line notes that a history record of the task aborting was written.
Now Pat could view the task details including the output files for the task to see why it aborted, and reset or delete
it. For information on troubleshooting failed tasks, see Troubleshooting Failed Tasks .

Troubleshooting Failed Tasks

In Applications Manager, a failed task usually is assigned an ABORTED status. Depending on the circumstances,
some tasks fail with a status other than ABORTED. All failed statuses are written in red and brought to the top of
the Backlog display. For a list of task status descriptions and actions, see Task Status Values.
When tasks abort, a system output file is generated which is available for viewing from the Applications Manager
client. The system output file is an excellent place to start troubleshooting. Along with runtime information and
parameters passed to the task, the file includes error messages. A sample system file is shown below.
To view system output files, you right click the task in the Backlog or History, select Output, then pick the standard
output file. In the image below, a standard output file named o12031.00 is selected in the File Viewer window.
From the viewer, you can view, print, FTP, or email the output file.
Applications Manager 9.4.1
 Applications Manager 9.4.1

The system output file includes basic information about the task such as:
• The name of the program executed.
• The person who ran the task.
• The Applications Manager run ID assigned to the task.
• The parameters used to run the task.
• A record of the basic steps taken to execute the task.
• Standard error reporting.
Getting More Information with Task Level Debug
If the system output file does not provide enough information to solve your problem, you can turn on the task level
debug. When task level debug is on, additional information is written to the task's system output file. If you call
Braodcom Support to help figure out why a task failed, they will most likely ask you to turn on task level debug,
reproduce the problem, and send in the log. Doing this ahead of time will speed you along to the quickest possible
resolution.
To turn on task level debug, create an empty file named BODY in the debug directory of the Automation Engine.

Taking Actions on Tasks in the Backlog

You can select one or more tasks in the Backlog and right-click to:
• Put tasks on hold.
• Kill tasks.
• Reset aborted, killed, or on hold tasks to allow them to run again.
• Delete tasks.
• Remove all predecessors for tasks.
To take an action on one or more tasks in the Backlog, highlight the task(s), right-click and select one of the first
five options from the pop-up window.
The number displayed to the right of each of these options tells you how many of the tasks you selected are eligible
for that action. If a * is displayed to the right of the number, one or more of the highlighted tasks is a Process Flow
in an INITIATED status.
Applications Manager displays a small animated window while an action is processing.
 Applications Manager 9.4.1

Necessary User Access

To take an action on a task, you need:
• The task's Job/Process Flow definition in one of your User Groups (with or without Edit authorization).
• The Explorer User Authority in a User Group with Edit authorization.
To take actions on tasks in the Backlog run by other Users, you must have the Edit Other Users' Tasks User
Option. For more information, see your Applications Manager administrator.
Taking Actions on Process Flows
Actions affect Process Flows headers and components differently depending on whether the Process Flow is in an
INITIATED status. Details for each action are described below:

Action When the Process Flow is not When the Process Flow is
INITIATED INITIATED

Hold Holds the Process Flow header. Holds all eligible components in the
Does not affect its components. Process Flow.
 Applications Manager 9.4.1

Action When the Process Flow is not When the Process Flow is
INITIATED INITIATED

Kill A Kill cannot be taken against Kills all eligible components in the
a Process Flow that is not in an Process Flow.
INITIATED status.

Reset Resets the Process Flow header. Resets all eligible components in the
Does not affect its components. Process Flow.

Delete Deletes the Process Flow header Deletes all eligible components in
and all its components.* the Process Flow.*

Remove all predecessors Removes all predecessors for the Removes all predecessors for the
Process Flow header. Does not Process Flow header. Does not
affect its components. affect its components.

* When Process Flows are deleted, skipped, or canceled the following will occur:
• All BEFORE conditions will be canceled.
• The Process Flow's children that are unstarted Process Flows will be initialized.
• All predecessors for the Process Flow's children will be removed.

Putting Tasks On Hold

If a task is in the Backlog but has not yet started, you can put it on hold. The task will remain in the Backlog in a
hold status until you reset it or delete it from the Queue. If a task has started running, you cannot put it on hold.
However, you can kill a running task. For information on killing a task, see Killing Tasks.
 Applications Manager 9.4.1

Procedure
To put tasks on hold:
1. Select one or more tasks in the Backlog and right-click.
Applications Manager displays the pop-up menu shown above. The number to the right of the Hold, Kill, Reset,
and Delete options references the number of tasks you have selected that are eligible for that operation.
2. Select the Hold option.
Applications Manager displays the Hold confirmation window.
3. Click Yes to hold the task(s).
Applications Manager closes the confirmation window and displays a small animated window to show you that it
is taking the hold action on the task(s).
Result
When you put a task on hold, its status is displayed in a hold status, such as HOLD or HOLD PRED WT.
Applications Manager displays the status bar at the bottom of the window in yellow to alert you that one or more
 Applications Manager 9.4.1

tasks are on hold. A record is written to the task's comment, noting that it was manually put on hold. The task
remains on hold until you reset the status or delete the task from the Backlog.

Taking Tasks Off Hold

To take tasks off hold:
1. Select one or more tasks which are on hold in the Backlog and right-click.
2. Click the Reset option.
Applications Manager will display the Reset confirmation window.
3. Click Yes to reset the task(s).
Applications Manager closes the window and changes the task's status to LAUNCHED.

Killing Tasks
If a task is running, you can kill it by selecting the task and using the Kill command. When you kill a task, it stays
in the Backlog until you delete or reset it. When you kill a task, Applications Manager makes an entry in History
showing that the task was killed.
 Applications Manager 9.4.1

Procedure
To kill running tasks:
1. Select one or more running tasks in the Backlog that you wish to kill and right-click.
Applications Manager displays the pop-up menu shown above. The number to the right of the Hold, Kill, Reset,
and Delete options references the number of tasks you have selected that are eligible for that operation.
2. Click the Kill option.
Applications Manager displays the Kill confirmation window.
3. Click Yes to kill the task(s).
Applications Manager closes the confirmation window and displays a small animated window to show you that
it is taking the kill action on the task(s). Once the task(s) go into a KILLED status, the Backlog label will be
displayed in its default color.
Result
While Applications Manager is killing a task, the task's status in the Backlog changes briefly to KILL. Once the task
is killed its status changes to KILLED, and an entry is made in History to show this (see image below). A record is
 Applications Manager 9.4.1

written to the task's comment, noting that it was manually killed. The killed task stays in the Backlog until you delete
it or reset it.

When you kill a task in Applications Manager running in a UNIX environment, Applications Manager issues the
kill -15 UNIX command followed by the kill -9 UNIX command.

Resetting Aborted and On Hold Tasks

If a task aborts and remains in the Backlog, is killed, or is put on hold, you can reset it directly from the Explorer
window. Before restarting a task, you can review its details including general task details, prompts, and conditions,
and correct any problems. When you restart a task that is aborted or on hold, its status changes to LAUNCHED. As
soon as a thread becomes available in the Queue, the status changes to QUEUED.
An aborted task stays in the Backlog if the Stay in queue on abort option was set when the Job was created. If
this option was not set, the task is cleared from the Backlog and an entry is displayed in History. You cannot restart
a task from the Explorer window once it has been removed from the Backlog. However, you can resubmit the task
by going to the Requests window.
 Applications Manager 9.4.1

Procedure
To reset one or more tasks from the Backlog:
1. If appropriate, change the task details.
For more information on changing task details, see Viewing and Editing Task Details.
2. Select one or more tasks in the Backlog and right-click.
Applications Manager displays the pop-up menu shown above. The number to the right of the Hold, Kill, Reset,
and Delete options references the number of tasks you have selected that are eligible for that operation.
3. Select the Reset option.
Applications Manager displays the Reset confirmation window.
4. Click Yes to reset the task(s).
Applications Manager closes the confirmation window and displays a small animated window to show you that it
is taking the reset action on the task(s). Once the task(s) go into a LAUNCHED status, the Backlog label will be
displayed in its default color.
Result
 Applications Manager 9.4.1

A record is written to the task's comment noting that it was manually reset. When a thread becomes available for
the Queue, Applications Manager will start the task(s).

Deleting Tasks
If a task in the Backlog is in a non-running status, you can delete it. For example, tasks with a status of
LAUNCHED, PRED WAIT, ABORTED or KILLED can be deleted. You can also delete Process Flows from the
Backlog. If you delete a Process Flow, all components in the Process Flow are deleted as well. When you have
deleted a task, you cannot reset it from the Explorer window.
 Applications Manager 9.4.1

Procedure
To delete tasks:
1. Select one or more tasks in the Backlog and right-click.
Applications Manager displays the pop-up menu shown above. The number to the right of the Hold, Kill, Reset,
and Delete options references the number of tasks you have selected that are eligible for that operation.
2. Select the Delete option.
Applications Manager displays the Delete confirmation window.
3. Click Yes to delete the task(s).
Applications Manager closes the confirmation window and displays a small animated window to show you that it
is taking the delete action on the task(s). Once the task(s) go into a DELETED status, the Backlog label will be
displayed in its default color.
Result
 Applications Manager 9.4.1

When you delete tasks, they are removed from the Backlog. A record of the task deleted from the Backlog is now
displayed in History with a DELETED status as shown below. An entry is also made in the task's comment, noting
that it was manually deleted. After deleting a task, you cannot reset it from the Explorer window.

How Deleting Process Flow Components Affects Process Flows

When you delete a task from a Process Flow, Applications Manager handles the predecessor links as follows:
• Internal predecessor links associated with the task are inherited by the next component in the Process Flow.
• External predecessor links for the task are removed.
If you delete the last internal predecessor link associated with a task, that component is moved to the upper right
corner of the Process Flow and will be eligible to run with any other component that shares its row.

Removing All Predecessors for Tasks

If a task in the Backlog is waiting for one or more predecessors before it can run, you can remove the
predecessor(s) to force it to run. To remove all predecessors for one or more tasks, select the task(s), and right-
click. Choose the Remove All Predecessors option from the pop-up menu.
 Applications Manager 9.4.1

To remove all predecessor links for a task in the Backlog, right-click the task and select Remove All Predecessors
from the pop-up menu as shown above. The task will then be eligible to run as shown below.
 Applications Manager 9.4.1

If you wish to view and remove select predecessors for a task, you can do so on the Predecessors tab of the Task
Details window. For more information, see Pending Predecessor Links: Viewing and Removing.
When you remove predecessor links for a task in the Backlog, the changes are applied only to that instance of the
task. They do not affect the definition of the Job or Process Flow.
Removing External Predecessors by Queue
To remove a task's external predecessors on insert to the Backlog, assign it to the
REMOVE_EXT_PREDS_ON_INSERT Queue. You can create the REMOVE_EXT_PREDS_ON_INSERT Queue
by hand or by importing it. For more information, see Removing External Predecessors by Queue.

Viewing and Editing Task Details

You can right-click any task in the Backlog or History and select an option from the pop-up menu shown below to
view its task details. The option you select determines which tab will be active on the Task Details window.
 Applications Manager 9.4.1

Editing Task Details

You can alter the details of tasks in a non-running status in the Backlog by doing any of the following:
• Editing general parameters such as a task's Queue, Login, or start time.
• Adding, changing, or deleting prompt values and predecessor links.
• Adding, changing, deleting, or copying conditions.
The changes you make apply only to the current instance of the task, and will not affect the task the next time it is
submitted.
To view the details for tasks submitted by other Users, you must have the View Other Users' Tasks User Option
assigned to you by your Applications Manager administrator. To edit their details, you must have the Edit Other
Users' Tasks User Option. To edit all the details for tasks in the Backlog, you will also need access to the objects
assigned to the Job/Process Flow.
Understanding Documentation, Output Files, and Task Comments
The following tabs on the Task Details window provide information about the task:
 Applications Manager 9.4.1

• Documentation: Information written by the person who created the Job or Process Flow. Documentation
provides relevant information about the processing of a task. It can be comments, suggestions, or instructions.
Documentation cannot be altered from the Explorer window.
• Output Files: Output files created on the Agent machine when the task is run. Output files include system and
application files for the task. Output files can be opened for viewing using the File Viewer window.
• Comments: Information about the running of a task. Applications Manager automatically creates comments that:
• Tell about condition actions that affect the running of a task.
• Detail DELETE, HOLD, RESET, and KILL actions taken by a User.
• Give details on tasks with a LAUNCH ERR status.
Additionally, you can include your own comments to provide relevant information about the processing of a task.
Comments are not files, and should not be confused with documentation or output files.

General Task Details: Viewing and Editing

General task details determine how and where a task runs, and with what options. When you edit task details for a
task in the Backlog, the changes are applied only to that instance of the task. They do not affect the definition of the
Job or Process Flow.
Editing General Task Details in the Backlog
To change the parameters associated with a task in the Backlog:
1. Right-click the task and select Task Details from the pop-up menu.
2. Applications Manager displays the Task Details window with the General tab selected as shown below.
 Applications Manager 9.4.1

3. Make the desired changes on the General tab.

You can select the other tabs to view and/or edit additional details for the task.
4. To accept the changes on all tabs, click OK.
View-only fields
• Alias
The alias name for the Job/Process Flow. You can specify an alias name when the Job or Process Flow is:
• Added to a Process Flow as a Process Flow component.
• Requested with the REQUEST JOB condition action.
• Requested using a task name suffix.
• Requested with awrun.
• Job
The name of the Job or Process Flow set in the Job/Process Flow definitions.
• User
The User or requestor assigned to the task. Users and requestors are the same thing. They are set for a Job or
Process Flow in a schedule or requests. Requestors can be set to 'No Selection' in schedules, in which case no
User will be listed.
 Applications Manager 9.4.1

• Run ID
A unique number assigned to a task by Applications Manager at the time the task runs.
• Process Flow Name
The parent Process Flow, if this task is a Process Flow component.
• Process Flow Order No.
The order number of the task in its Process Flow, if the task is a Process Flow component.
• Request Date
The actual time that the task was placed into the Backlog. Corresponds to the so_request_date database field.
• Started
The actual time that the task was started by the Automation Engine and processed by the Agent. Corresponds
to the so_job_started database field.
• Ended
The actual time the task finished processing on the Agent. Corresponds to the so_job_ended database field.
• Status
The task status. For a description of the task status values, see Task Status Values.
• Process ID
A unique number assigned to a task by the operating system.
• Status Detail
Details that give additional information on the reason for a task's status.
• Other Details
When clicked displays a pop-up window with the application status and reference fields. These are used with
the PeopleSoft extension and some custom solutions.
• Notification, Output Scan, Environment Variables
Lists the Notification, Output Scan, and Environment Variable objects assigned to the task and where they are
assigned.
Editable fields
• Max Run Time
Used to prevent runaway programs. It determines how long the program can run before timing out
(DDD:HH:MI). A time of 0 lets the task run forever. If a task times out, it is given a status of TIMEOUT.
• Priority
Determines when a Job is run in relation to other tasks in the same Queue. A task with a lower priority number
will be run before tasks with higher numbers. The range is 1-99. The default priority is 50.
Tasks submitted with 0 priority will have the status of NO PRIORITY in the Backlog and will not run.
The execution order of tasks waiting to run in a QUEUED status is decided in the following order:
1. Queue priority
2. Job priority
3. Start date and time
Therefore, if two tasks are waiting to run in different Queues, and those Queues have the same priority, the
Jobs' priorities are checked. If Queue and Job priorities are the same, their start date and times are compared.
• Login
The Login the system will use when the task is executed. Logins allow operators and programmers to run
programs that access a database or host without having to know the login and password.
Primary and secondary Logins can be specified for Jobs. The primary Login can be overridden (if one is defined
for the Job) by:
• Jobs requested with the REQUEST JOB condition action.
• Process Flow components.
• Queue
The Applications Manager Queue the task will run through. Queues are assigned to Jobs and Process Flows.
If a schedule is defined for a Job or Process Flow, and the schedule is assigned to a Queue, the schedule's
 Applications Manager 9.4.1

Queue will override the Jobs or Process Flow's Queue. The Queue setting for a Process Flow does not affect
its components, unless the Insert components into Process Flow's Queue Automation Engine option is
turned on.
The Process Flow's Queue is used for components only when the Insert components into process flow's
queue Automation Engine option is turned on.
Queues can be specified for requests (as long as the Request Queues User Option is assigned).
• Agent
The Agent where the program is stored and run.
• Start Date
The time that the task was scheduled to start. Corresponds to the so_start_date database field. Start dates for
tasks in the Backlog are determined by either:
• Requests (may be post-dated).
• Schedules for Jobs and Process Flows.
• The schedule of a component's Process Flow.
• Send To
Specifies the Output Device or set of devices where the output will be sent (for example: EMAIL, ACCOUNTING
LASER, ATLANTA LASER).
• Output Option
Used for specifying dynamic output options for the selected Output Device. This value or list of values is defined
by the Output Interface assigned to the Output Device.
• Output Function
Determines how output is handled. There are three choices:
• LOG: Legacy setting, should not be used unless you need to use the Output window rather than the
Explorer window.
• PRINT: The output is printed.
• STORE: The output is not printed.
• Copies
Sets the default number of copies to be printed.
• Restart once on abort
When selected, Applications Manager will automatically restart a task the first time it aborts, but will not restart it
if it aborts a second time.
When this option and the Stay in Queue on abort option are both set, and the task aborts, you will see three
listings for it in the Explorer window.
• The original listing for the Run ID <run_id> in History shows that the task ran.
• A second listing <run_id>.01 in History shows that it aborted.
• The current listing <run_id>.02 in the Backlog represents the restarted task.
The Restart once on abort setting is specified in each task's definition, and can be overridden with a condition.

Task Prompts: Viewing and Editing

Prompts pass user input to the program run by a task. Prompts for a task, either a Job or a Process Flow, can be
viewed and edited from the Backlog and viewed from History. Prompts are defined by the individual that created the
Job or process flow.
Viewing Prompts
To view the prompts for a task, right-click a task in the Backlog or History and choose Prompts. Applications
Manager displays the Task Details window with the Prompts tab selected as shown below.
 Applications Manager 9.4.1

Editing Prompts in the Backlog

To edit the prompts for a task in the Backlog:
1. Right-click the task and choose Prompts from the pop-up menu.
Applications Manager displays the Task Details window with the Prompts tab selected.
2. Click to select a prompt.
3. You can edit the prompt values for each task.
When you edit prompts for a task in the Backlog, the changes are applied only to that instance of the task. They
do not affect the definition of the Job or Process Flow.
You can select the other tabs to view and/or edit additional details for the task.
4. Click OK to accept the changes and exit to the Explorer window.

Pending Predecessor Links: Viewing and Removing

Applications Manager controls task flow with predecessors. When a task is waiting to run due to predecessor
requirements, you can view its pending predecessors. If you want to run the task immediately, you can remove the
pending predecessor links.
Viewing Pending Predecessors
To view pending predecessors for a task, right-click the task and select Predecessors from the pop-up menu.
Applications Manager displays a table listing each task that is a predecessor as shown below.
 Applications Manager 9.4.1

The Predecessors tab is divided into two panes:

• The External Scheduled Predecessors pane in the upper part of the tab lists the tasks which are
predecessors of the selected task and are not in the Backlog. If tasks are not in the Backlog, but are scheduled
to run in the current virtual day, their scheduled start time will be shown in the Schedule column.
• The Predecessors in Backlog pane in the lower part of the tab lists the tasks which are predecessors of the
selected task and are currently in the Backlog.
To view the predecessor statement for a task, select the task and click the Pred statement button. Applications
Manager displays the predecessor statement in the Predecessor Expression window shown below.

To view the task details for a task in the table, right-click the task and select an option.
Understanding Predecessor Link Types
Descriptions for each link type are given below:
• Started: Predecessor must have started or been skipped. Represented by a solid yellow line.
• Success since last run: For external predecessors only. Predecessor must complete with a status of
FINISHED since the last time this Job ran. Represented by a dashed blue line.
• Success (default): Predecessor must complete with a status of FINISHED or be removed from the Backlog.
Represented by a solid green line.
• Success only when FINISHED: For external predecessors only. Predecessor must complete with a status of
FINISHED. Represented by a solid blue line.
• Success (skip on failure): Predecessor must complete with a status of FINISHED. If status is ABORTED,
DIED, or TIMEDOUT, the component is skipped. Represented by a dashed green line.
 Applications Manager 9.4.1

• Failure: Predecessor must complete with a status of ABORTED, DIED, or TIMEDOUT. Represented by a solid
red line.
• Failure (skip on success): Predecessor must complete with a status of ABORTED, DIED, or TIMEDOUT. If
status is FINISHED, the component is skipped. Represented by a dashed red line.
• Complete: Predecessor completes with any status including FINISHED, DIED, or ABORTED. Represented by
a solid black line. Predecessor links to a Process Flow must use this predecessor link type or the Success link
type.
Removing Predecessor Links
To remove predecessor links from either pane of the Pending Predecessors window, check the box in the
Remove column for the task and click the Apply button. Applications Manager deletes the predecessor link. If
there are no other predecessor links, the task should run. This has the same effect as deleting a predecessor link
from the referenced task's Flow Diagram tab.
Deleting predecessor links from this tab does not delete tasks from the Backlog.
If you wish to remove all predecessor links for a task in the Backlog, you can do so by right-clicking and
selecting the Remove All Predecessors option from the pop-up menu. For more information, see Removing All
Predecessors for Tasks.
When you remove predecessor links for a task in the Backlog, the changes are applied only to that instance of the
task. They do not affect the definition of the Job or Process Flow.
Removing External Predecessors by Queue
To remove a task's external predecessor links on insert to the Backlog, assign it to the
REMOVE_EXT_PREDS_ON_INSERT Queue. You can create the REMOVE_EXT_PREDS_ON_INSERT Queue
by hand or by exporting it. For more information, see Removing External Predecessors by Queue.

Successors in the Backlog: Viewing

When a task is in the Backlog, it may be a predecessor to other tasks. Other tasks that have predecessor links to a
task are called its successors.
Viewing Successors
To view successors for a task, right-click the task and select Successors from the pop-up menu. Applications
Manager displays a table listing each successor as shown below.

To view the task details for a task in the table, right-click the task and select an option.

Task and Predecessors in a Flow Diagram: Viewing, Adding, and Editing

Predecessors must be met before a task will be eligible to run. They are evaluated prior to any BEFORE conditions
the task might have. They can be viewed from the Backlog and History.
The Flow Diagram tab shown below has a left pane where the Process Flow or Job is displayed, and a right
pane where the Predecessor Editor is displayed. Process Flow components in the Predecessor Editor box
will be written in the format <Process Flow name>/<component name>. You can right-click a predecessor in the
Predecessor Editor box to change or edit it. You can resize the panes by dragging the splitter bar, and minimize or
maximize the panes using the arrows at the top of the splitter bar.
 Applications Manager 9.4.1

From the Flow Diagram tab, you can monitor and manage objects in much the same way as from Explorer. You
can edit predecessor links as well as take actions on tasks such as delete, hold, restart, and kill.
Viewing Predecessor Links in a Flow Diagram
To view the predecessor links for a task in a flow diagram, right-click the task and select Flow Diagram from the
pop-up menu. Applications Manager displays the Task Details window with the Flow Diagram tab selected.
External references to scheduled tasks that are not yet in the Backlog will have a dashed border.
Adding and Editing Predecessor Links in a Flow Diagram
You can add, edit, or delete internal and external predecessor links for non-running tasks in the Backlog. An
internal predecessor link is a link to a component within the parent Process Flow. An external predecessor is a
link to a component outside the parent Process Flow. When you edit a link, you can change the link type, redirect
the link to another component, or delete the link. You can also add external predecessor links for these tasks. You
cannot add components to a Process Flow from the Backlog.
 Applications Manager 9.4.1

When you add, edit, or delete predecessor links for a task in the Backlog, the changes are applied only to that
instance of the task. They do not affect the definition of the Job or Process Flow.
You can select the other tabs to view and edit the task's general task details, prompts, documentation, output, and
more.
Disabling Pop-Up Tables
You can disable the pop-up tables by unchecking the Show status info option under the Options menu. The
Show status info setting can be saved for your workstation by selecting Save Preferences from the File menu.
Taking Actions on Tasks and Viewing or Editing Task Details
You can right-click tasks in the Flow Diagram tab to take actions on them or to view or edit their task details the
same way you would in the Explorer window. For more information on taking actions on tasks, see Taking Actions
on Tasks in the Backlog. For more information on viewing and editing task details, see Viewing and Editing Task
Details.

Task Conditions: Viewing and Editing

Conditions control the execution of tasks. They can be evaluated before, during, and after a task executes, and
after a task is deleted. Conditions for a task can be viewed from the Backlog and History. Conditions can be added,
edited, or deleted from tasks in the Backlog for a single running of the task.
Procedure
To view the conditions for a task, right-click the task and select Conditions from the pop-up menu. Applications
Manager displays the Task Details window with the Conditions tab selected as shown below.
 Applications Manager 9.4.1

To add, edit, delete, or copy a condition for a task in the Backlog, select the appropriate button. When you make
changes to conditions for a task in the Backlog, the changes are applied only to that instance of the task. They do
not affect the definition of the Job or Process Flow. You can select the other tabs to view or edit the task's general
task details, prompts, documentation, output, and more.
Where Conditions Are Defined
Conditions can be defined for Jobs, Process Flows, and Process Flow components. The conditions are not
included when the Job/Process Flow is assigned to a Process Flow unless the Use Job Conditions option is
checked for the component.

Task Documentation: Viewing

Documentation is written by the person who created the Job or Process Flow. It provides relevant information
about the processing of a task. Documentation can be comments, suggestions, or instructions. You can access
documentation from the Backlog or History, when it has been included.
 Applications Manager 9.4.1

Documentation Assigned to Objects

Documentation can be assigned to three different objects in Applications Manager:
• Jobs:Job documentation is used when a Job is going to be requested ad hoc, or when the documentation for a
Job would be useful—regardless of how it is invoked.
• Process Flows: Process Flow documentation is used to provide information about the entire Process Flow.
• Process Flow Components: Process Flow component documentation is used to provide information that is
specific to a Process Flow component.
All documentation for a task is displayed on the Documentation tab of the Task Details window.
Types of Documentation
There are two types of documentation: abort and general. Abort documentation provides instruction or information
for when the task aborts. General documentation provides information about the function of the Job or Process
Flow. Both types of documentation are available for viewing at all times regardless of task status.
Procedure
To view the documentation for a task in the Backlog or History:
1. Right-click the task in the Backlog or History and select Documentation from the pop-up menu. If
Documentation is grayed out on the pop-up menu, the task has no documentation.
You can right-click Process Flow components in the Backlog or History panes or in the icon tree.
Applications Manager displays the Task Details window with the Documentation tab selected as shown below.

If the task has HTML documentation, you can uncheck the HTML box to view the source HTML code.
2. In the top portion of the window, select the type of documentation you wish to view.
 Applications Manager 9.4.1

Applications Manager displays the documentation you selected in the bottom portion of the window.
You can select the other tabs to view and/or edit additional details for the task.
3. Click OK to close the window.

Task Output Files: Viewing

After a task finishes executing, it is moved into History. You can see how the task was executed by viewing the
task's standard output file. This can be useful for troubleshooting tasks that fail. You can also view output files
generated by the task.
Procedure
To view the output files generated by a task after it completes executing:
1. Right-click the task and choose Output Files from the pop-up menu.
Applications Manager lists the system and application output files for the task on the Output Files tab of the
Task Details window.
 Applications Manager 9.4.1

When Job definitions include Program Types that ship with Applications Manager, standard output and error
file names begin with an 'o'. Output files generated by the task begin with a 'b'. If custom Program Types are
assigned to your Jobs, their output files may be named differently.
 Applications Manager 9.4.1

The list for Process Flows will include the output files of all its components.
2. To print an output file without opening the File Viewer window, select a task and click the Print button or one of
the Print icons. For more information on printing output files, see Printing, FTPing, and Emailing Output Files.
3. To view a file, select the file and click View.
Applications Manager displays the File Viewer window. For information on using the File Viewer window and
printing output files, see Viewing Output Files with the File Viewer.
You can select the other tabs to view and/or edit additional details for the task.

Task Comments: Adding and Viewing

Task comments provide information about the running of a task. Applications Manager automatically creates
comments that:
• Detail actions taken by a User.
• Tell about condition actions that affect the running of a task.
• Give Output Scan details when rules are met.
• Give details on tasks with a LAUNCH ERR status.
Additionally, you can include your own comments to provide relevant information about the processing of a task.
You access, add, and query comments from the Backlog or History.

Viewing and Adding Comments for a Task

To view comments and add an comment to a task:
1. Right-click the task and choose Comments from the pop-up menu.
Applications Manager opens the Task Details window with the Comments tab selected as shown above. If
there are any entries for the task, they are displayed in the Log box. Each entry includes the user name of the
person who wrote the comment, and the date and time it was submitted. In the image above, there are two
entries associated with this task.
2. To add an entry to the task, enter text in the New Entry box at the top of the window and click Add.
Applications Manager adds the entry to the Comment box.
3. To save the entry and keep the window open, click Apply.
4. To save the entry and close the window, click OK.
 Applications Manager 9.4.1

After you have added an comment entry, you cannot change it. It becomes a permanent part of the task's history.
Querying Comments for Other Tasks
To view comments for another task:
1. From the Task Details window, select the Comment Query tab.
The table on the top of the screen displays all previous comments for the selected Job or Process Flow.

2. Select a comment from the table to view its text below.

3. To view comments for other Jobs/Process Flows, select the Job/Process Flow from the Job drop-down box You
can also query by keywords in the text.
Viewing a Comment Report
To view a report of comments, select Explorer Reports from the Reports menu on the Explorer window. This will
open the Reports window with the Explorer reports selected. Select the AW_OPERATOR_LOGS report and click
Show.

Unsatisfying Tasks as External Predecessors in History

There may be times when you run a task that serves as an external predecessor to one or more other tasks, and
you need to rerun the task. This may happen when the task completes successfully, but is run with incomplete
data.
 Applications Manager 9.4.1

To disallow predecessor links to this task, you must unsatisfy it as a predecessor. Once a task is unsatisfied as a
predecessor, it is as if it did not run. All predecessor links to it will not be satisfied until the Job, Process Flow, or
Process Flow component runs again.

Procedure
To unsatisfy a task as a predecessor for all potential predecessor links, right-click the task listing in History and
select Unsatisfy for Predecessors from the pop-up menu. Applications Manager changes the task's status to
UNSAT-FINISH and unsatisfies this running of the task as a predecessor for all predecessor links which reference
it, as shown below. The predecessor links of other tasks will now need to be satisfied by another instance of this
Job, Process Flow, or Process Flow component.
 Applications Manager 9.4.1

Viewing History in a Gantt Chart

To view one or more tasks in History in a Gantt chart format, select the tasks, right-click and choose the History
Gantt view option. If you select Process Flows or Process Flow components, Applications Manager displays all
tasks in the corresponding Process Flow(s).
Procedure
To view one or more tasks in History in a Gantt chart format:
1. Select one or more tasks in History.
2. Right-click and choose the History Gantt view option as shown below.
 Applications Manager 9.4.1

Applications Manager opens the History Gantt view window shown below.
 Applications Manager 9.4.1

If you select Process Flows or Process Flow components, Applications Manager displays all tasks in the
corresponding Process Flow(s).
For detailed information on the features available in all Gantt windows, see chapter Monitoring and Managing
Tasks with the Gantt View.
3. If you wish, you can right-click a task and select Flow Diagram to view its predecessors in a flowchart view.

Comparing Run Times in a Gantt Chart

Using a History query and the History Gantt view window, you can compare run times of tasks in History.
 Applications Manager 9.4.1

Procedure
To compare run times of tasks in History:
1. Select two or more records for Jobs and/or Process Flows in History that you want to compare.
You may want to run a History query of the tasks you wish to compare. For information on running History
queries, see Querying for Tasks in History.
In the image above, two instances of the INV_STATUS Job are selected.
2. Right-click the History Gantt view option from the pop-up window.
Applications Manager opens the History Gantt view window shown below.
 Applications Manager 9.4.1

3. In the History Gantt view window, select Set start times to midnight from the Actions menu.
4. Applications Manager displays all start times as midnight so you can compare run times as shown below.
 Applications Manager 9.4.1

How Applications Manager Handles System Failures

If your system fails for minutes, hours, or days, the Applications Manager modular Process Flows ensure orderly
recovery. Applications Manager keeps a record in its Oracle database of each task and the task's status. When
you bring your system back up, Applications Manager restores each task to the status it had at the time the system
went down.
How Applications Manager Handles Tasks in the Backlog
If the machine where the Applications Manager Automation Engine is installed goes down, Applications Manager
goes through a recovery procedure when the machine comes back up. The table below describes how Applications
Manager handles tasks that have already been submitted and are displayed in the Backlog.

Task status at time of crash Task status after recovery

Starting or Running Applications Manager checks to see if the task process

ID exists. If it exists, the status will be RUNNING. If the
task process ID does not exist, the status will be DIED.
You can restart the task from the Backlog.

Thread Wait Status will be THREAD WAIT.

Date Pending If the scheduled start date is still in the future, the status
will be DATE PENDING. If the start date has passed,
Applications Manager will launch the task as soon as
possible after the system is brought back online.
 Applications Manager 9.4.1

Task status at time of crash Task status after recovery

Finished The task will be moved to History with a status of

FINISHED.

Aborted If the Restart once on abort option is selected for

the Job, and this is the first time the task has aborted,
Applications Manager will run the task as soon as
possible after the system is brought back online.

The Effect of Agent and Network Failures

The following table describes what happens when a task is running and the Agent, Agent machine, or network goes
down.

When a task is running AND the machine AND the network THEN
and the Agent running the Agent

is up is up is up The status is RUNNING.

goes down The status of the task

in the Backlog is not
changed, however the
Agent will continue to
monitor the task. When
the network comes back
up, Applications Manager
checks with the Agent
and updates the status as
RUNNING, FINISHED, or
ABORTED.

goes down is up The status of the task

in the Backlog is not
changed. When the
machine and Agent come
back up, Applications
Manager marks the task
as DEAD. You can restart
the task from Applications
Manager.

goes down is up is up The status of the task

in the Backlog is not
changed. When the
Agent comes back up,
Applications Manager
checks if the task
completed. If the task
completed, Applications
Manager Reports the
status. If the task did not
complete, Applications
Manager will look for the
task's PID. If it finds the
PID, it will mark the status
as RUNNING. If it does not
find the PID, it will mark the
status as DEAD.

How Schedules Impact Recovery

 Applications Manager 9.4.1

Jobs and Process Flows scheduled to run during the down time will run once when the system is brought back up.
They will then return to their normal schedule. It does not matter how many times the Job or Process Flow was
scheduled to run during the down time. Each Job or Process Flow will run only one time before returning to its
normal schedule, unless a date was entered in the Reschedule from field.
If the Oracle Tables Are Lost
If the Applications Manager Oracle tables are lost as a result of the system failure, all status information will be
lost. You will need to restore the Oracle database and let Applications Manager resume processing based on the
schedule information restored by the backup.

Querying and Filtering Explorer

History queries help you find records in the Applications Manager database for tasks that have run and Agent/RMI
statuses that have changed. Results for History queries are displayed in the History pane of the Explorer window.
When a History query is active, the History pane is not refreshed. If you want to view updated query results, you
must re-run the query.
Backlog & History filters allow you to limit the entries in the Backlog and History displays on the Explorer window.
Results from Backlog & History filters are limited to the tasks and records currently in the Backlog and History
display. When a Backlog & History filter is active, the lists in the Backlog and History panes on the Explorer
window continue to refresh.
You run History queries and Backlog & History filters by picking an option from the Filter menu on the Explorer
window as shown below.
 Applications Manager 9.4.1

What Is the Backlog?

The Backlog is a list of tasks that:
• Are waiting to run.
• Are running.
• Have run and failed, and have stayed in the Backlog for operator intervention.
To view all tasks in the Backlog in the content pane on the top right side of the screen, click the Backlog icon in the
object tree shown in the image above. In the image above, some tasks are running, some are waiting in a PRED
WAIT status, and one task has aborted.
Whether a task remains in the Backlog when it fails is determined by the Stay in queue on abort setting in its Job
definition.
 Applications Manager 9.4.1

You can type the first few letters of an task from the Backlog's name in the Search field, and Applications Manager
will find it. The Search field accepts valid UNIX regular expressions. For example, to search for all Jobs starting
with the letters A and T, you would enter [at] in the Search field.
What Is History?
History is an audit trail including records for:
• All completed tasks and occurrences of task failure(s).
• RMI servers or Agents being started, stopped, or having errors.
• AgentService processes being stopped.
How long task history records are archived in the Applications Manager database is determined by the prompt
setting for the HISTORY_PURGE Job, which is part of the SYSTEM Process Flow. The default value is 60 days.
Your Applications Manager administrator is responsible for setting this value.
The Explorer window includes a partial view of History in its lower right pane.
The amount of History displayed when any user logs in to the client is determined by the HistoryRetentionTime
setting in the Options.properties file.
How long records are displayed in the History pane while you are logged into a Applications Manager session is
determined by:
• Your History Display Minutes desktop setting. For more information, see Editing General Desktop and ToolBar
Settings.
• Whether you have a History query activated.

Querying for Tasks in History

To perform a History query for the Explorer window, open the Filter menu and choose History Query. Applications
Manager displays the History Query window shown below.
 Applications Manager 9.4.1

You select search criteria for your query. You can query by one or more options by entering values in as many fields
as you like. Fill in the fields by doing one or both of the following:
• Typing in values
• Selecting values from a list
You may select a default sort order for the query by selecting a Sort option at the end of a field. The sort order can
be overridden from the History pane by selecting a different column name.
When you are through defining the query, click OK. Applications Manager displays a small animated window as it
processes the query. Once the query is processed, Applications Manager displays the results in the History pane of
the Explorer window.
Field descriptions for the History Query window are described below. Directions for the two methods of filling in the
fields follow.
• Jobs
Searches for any task assigned to the specified Job(s).
To query for a task run under an alias, enter the alias name.
• Process Flows
Searches for Process Flow(s) and components.
• Applications
Searches for any task assigned to the specified Application(s).
• Agents
 Applications Manager 9.4.1

Searches for any task run on the specified Agent(s).

• Queues
Searches for any task run on the specified Queue(s).
• Requestors
Searches for any task run by the specified User(s)/requestor(s). To use this field, you must have those Users in
an User Group with Edit authority.
• Status
Searches for any task assigned the specified task status(es). For a description of the task status values, see
Task Status Values.
• From start time/To start time
These fields accept date/time information. If the Current day option is selected, the From start time and To
start time fields will be inactive.
If you save a query for tasks run in the last two days, it will always run a query for the tasks in the last two days.
There is no way to save a query from a specific date.
• Run ID
This field references the unique number assigned to each task by Applications Manager. When using this field
do not include the decimal values.
• Current day
The default is to query by the current virtual day. If you save a query with this option checked, it will be applied
each time you run the saved query.
If you uncheck the option, the From start time and To start time fields become active. You can then enter
specific dates and times for the query.
Typing in Values
You can type comma-separated names in the fields. These fields also allow the use of:
• Wildcards: The _ wildcard is used to represent a single character, and the '%' wildcard represents an unlimited
number of characters.
• Negative filters: The ! character is used as a negative filter to exclude tasks from the search. For example,
entering !AW% will exclude tasks with the letters AW together in their name.
Selecting Values from a List
When you click on an icon at the end of one of the applicable fields in the History query window, Applications
Manager displays the object assignment window where you can pick one or more objects. The windows will
list only the objects to which you have User Group access. Use the arrow buttons to move objects between the
Unassigned and Assigned tables. For information on assigning objects, see Working in the Applications Manager
Windows.
Use the Search field to query the Unassigned table. You can apply the search criteria to the Assigned column as
well by unselecting the Show all assigned option.
You can use negative filters to exclude tasks from the search based on the items you select by checking the
Negative Filter box before assigning objects. When an object is added as a negative filter, it will have the !
character before its name in the Assigned table.
 Applications Manager 9.4.1

Use the Other filters field to type in comma-separated names. This field allows for wildcards and negative filters as
described in the "Typing in Values" section above.
Any text entered in the Other filters field will be included in the appropriate field on the Select filters window.
Adding the Queried Results to History
By default Applications Manager limits the records in the History pane to the results of the query. If you would rather
add the queried results to the current History display, click the Add to Current History box on the History Query
window.
When you add the queried results to the current History display, the records will be added to the History pane and
the Apply Query box on the Explorer window will not be checked. The records added from the query will remain
in History for the number of minutes you have defined in your History Display Minutes desktop setting. To see them
again, you can run another query. For more information on the History Display Minutes desktop setting, see Editing
General Desktop and ToolBar Settings.
Saving a Query
You may also optionally save a History query to use later by entering a name in the Filter name drop-down box
The History query will be saved when you click OK.
Saved History queries can be recalled from the Filter name drop-down box for History queries, Output queries, and
filters of the Backlog and History.
You can delete a saved query by selecting it and clicking Delete.
Viewing Query Results
When you run a query, the Apply Query checkbox will be selected and the column headers will be displayed with a
light orange background as shown below.
 Applications Manager 9.4.1

Applications Manager will not refresh the query's results. If you want to view updated query results, you must re-run
the query.
To view the unqueried History, uncheck the Apply Query box. You can view the queried results again by
rechecking the Apply Query box. If you select the History Query menu item again, Applications Manager returns
you to the Query Definition window. Applications Manager displays the search criteria you defined on your last
query. To run a new query, select new data and click OK.

Filtering the Backlog and History

Backlog & History filters allow you to limit the entries in the Backlog and History displays on the Explorer window.
Results from Backlog & History filters are limited to the tasks and records currently in the Backlog and History
display.
To perform a Backlog & History filter of the Explorer window, open the Filter menu and choose Filter Backlog and
History. Applications Manager displays the Select filters window shown below.
 Applications Manager 9.4.1

You select search criteria for your filter. You can filter by one or more options by entering values in as many fields
as you like. Fill in these fields by doing one or both of the following:
• Typing in values
• Selecting values from a list
You may select a default sort order for the query by selecting a Sort option at the end of a field. The sort order can
be overridden from the Backlog or History panes by selecting a different column name.
When you are through defining the filter, click OK. Applications Manager displays a small animated window as
it processes the filter. Once the filter is processed, Applications Manager displays the results in the Backlog and
History panes of the Explorer window.
Field descriptions for the Select filter window are described below. Directions for the two methods of filling in the
fields follow.
• Jobs
Searches for tasks assigned to the specified Job(s), including tasks running the Job under an alias name.
To query for a task run under an alias, enter the alias name.
• Process Flows
Searches for the selected Process Flow(s) and their components.
• Applications
Searches for any task assigned to the specified Application(s).
• Agents
 Applications Manager 9.4.1

Searches for any task run on the specified Agent(s).

• Queues
Searches for any task run on the specified Queue(s).
• Requestors
Searches for any task run by the specified requestor(s).
• Status
Searches for any task assigned the specified task status(es). For a description of the task status values, see
Task Status Values.
This is a common field where negative filters are used. For example, if !ST% is entered in this field, Applications
Manager will not display components in various staged statuses in the Backlog including: STAGED, STG SKIP,
STAGED HOLD, STG_PW HOLD, and STAGED_PW.
• From start time/To start time
These fields accept date/time information. If the Current day option is selected, the From start time and To
start time fields will be inactive.
If you save a filter for tasks run in the last two days, it will always run a filter for the tasks in the last two days.
There is no way to save a filter from a specific date.
• Run ID
This field references the unique number assigned to each task by Applications Manager. When using this field
do not include the decimal values.
• Current day
The default is to query by the current virtual day. If you save a query with this option checked, it will be applied
each time you run the saved query.
If you uncheck this option, the From start time and To start time fields become active. You then can enter
specific dates and times for the query.
• Future Hours
This field is used to look ahead X number of hours for staged tasks and requested tasks with a start date/time in
the future. It works in conjunction with the From start time and To start time fields, with Applications Manager
calculating the greatest time span based on both criteria.
Typing in Values
You can type in comma-separated names in the fields. These fields also allow the use of:
• Wildcards: The _ wildcard is used to represent a single character, and the % wildcard to represent an unlimited
number of characters.
• Negative filters: The ! character is used as a negative filter to exclude tasks from the search. For example,
entering !AW% will exclude tasks with the letters AW together in their name.
Selecting Values from a List
When you click on an icon at the end of one of the applicable fields in the History query window, Applications
Manager displays the object assignment window where you can pick one or more objects. The windows will
list only the objects to which you have User Group access. Use the arrow buttons to move objects between the
Unassigned and Assigned tables. For information on assigning objects, see Working in the Applications Manager
Windows.
Use the Search field to query the Unassigned table. You can apply the search criteria to the Assigned column as
well by unselecting the Show all assigned option.
You can use negative filters to exclude tasks from the search based on the items you select by checking the
Negative Filter box before assigning objects. When an object is added as a negative filter, it will have the !
character before its name in the Assigned table.
 Applications Manager 9.4.1

Use the Other filters field to type in comma-separated names. This field allows for wildcards and negative filters as
described in the "Typing in Values" section above.
Any text entered in the Other filters field will be included in the appropriate field on the Select filters window.
Viewing Filter Results
Applications Manager runs the search and displays the filtered results. The Apply Filter checkbox will be selected
and the column headers will be displayed with a orange background as shown in the image below. To view the
unfiltered Backlog and History, uncheck the Apply Filter box. You can view the filtered results again by rechecking
the Apply Filter box. If you select the Filter Backlog & History menu item again, Applications Manager returns
you to the Select filters window. Applications Manager displays the search criteria you defined on your last filter.
To run a new filter, select new data and click OK. To select a saved filter, select it from the drop-down box between
the two checkboxes in the History pane.
 Applications Manager 9.4.1

Staging Tasks in the Backlog

By default, scheduled tasks appear in the Backlog when they are ready to run. To bring them into the Backlog
ahead of time, you can stage tasks up to 48 hours in the future.
Staging tasks in the Backlog gives you the opportunity to:
• View scheduled tasks in the Backlog before they run.
• Alter a task's details before it runs.
• Delete a task before it runs.
For information on altering task details, see Viewing and Editing Task Details.
 Applications Manager 9.4.1

How Tasks Are Staged

Tasks are staged by running the either the STAGING or STAGING_BY_SCHEDULE Jobs. When you run one
of these Jobs, you tell Applications Manager which tasks to stage by specifying prompt values. They can be
scheduled or requested ad hoc. For more information, see Staging Tasks.
Staging and the Virtual Day
The virtual workday is a point in time each day that limits how far back Applications Manager will search in the
Backlog and History for a predecessor. When a task is staged, its virtual day is set based on its start time.
Lights Out vs. Operations-Intensive
There are two basic Applications Manager environments:
• Lights out: No one monitors Applications Manager. Tasks run based on their schedules, predecessor links, and
conditions. An email or page is sent out when tasks or Agents have trouble.
• Operations-intensive: Operators monitor and manage Applications Manager. Some tasks are scheduled, while
others are requested ad hoc. Operators are often called to change runtimes of tasks or to edit tasks before they
run.
 Applications Manager 9.4.1

Most customers function somewhere in the middle.

Staging for Lights Out Shops
If you are strictly a lights out shop, there is little need to stage tasks. You would not need to schedule the STAGING
or STAGING_BY_SCHEDULE Jobs. In the rare cases when you need to make changes for the running of a task,
you could request one of them ad hoc for one task only.
Staging for Operations-Intensive Shops
If you are an operations-intensive shop, you may want to stage tasks in a few different ways. One would be to
stage all tasks that will run during each operator's shift. All tasks for an eight hour period would be listed in the
Backlog. This way operators can see everything that is going to run and quickly edit tasks when they are instructed
to. A second method would be to stage only particular tasks. You might do this if several tasks are scheduled, but
only a few typically need to be edited. A third method would be to only stage tasks when changes need to be made.
Operators might do this if they do not want a lot of scheduled tasks shown in the Backlog.

Staging Tasks
Applications Manager staging allows you to edit tasks before they run. You tell Applications Manager which tasks
to stage by specifying prompt values and running either the STAGING or STAGING_BY_SCHEDULE Job. These
Jobs can be scheduled or requested on an ad hoc basis. Jobs and Process Flows should not be edited, and you
should not run exports or imports while these Jobs are running.
 Applications Manager 9.4.1

Two Staging Jobs

The STAGING and STAGING_BY_SCHEDULE Jobs both ship with Applications Manager. They allow you to stage
Jobs and Process Flows. The difference between the two Jobs is their second prompt.
Which staging Job you want to run depends on whether you want to stage Jobs and Process Flows based on all of
their schedules or some of their schedules. For example, you may want to stage a Job that includes two schedules
that run with different prompt values for different departments. To make sure you stage the correct task, you would
stage the Job by running STAGING_BY_SCHEDULE.
Prompt Values
The staging Jobs include the following prompts.
• Applications to be Staged
Use the Select button to select one or more Applications Manager Applications.
• Flows/Jobs or Flows/Jobs->Schedule Name
Use the Select button to select:
 Applications Manager 9.4.1

• For STAGING: individual Jobs and Process Flows with schedules from the Application(s) selected in the first
prompt.
• For STAGING_BY_SCHEDULE: schedules from Jobs and Process Flows with schedules from the
Application(s) selected in the first prompt.
If one or more Applications are selected, but no Process Flows or Jobs, then all Process Flows/Jobs of the
selected Applications will be staged. Any scheduled Process Flows or Jobs not staged will be inserted in the
Backlog at their regularly scheduled time.
• Include Hour/Minute Schedules
Determine whether you wish to include Process Flows/Jobs with Hours or Minutes selected in their schedule's
Units box.
• Hours ahead to be staged
Determine the number of hours ahead you want to stage tasks.
By default, this prompt has a maximum value of 48 hours. This is so no one accidentally stages out too far. If
you wish to stage tasks out longer, you must edit the prompts in the Job's definition.
If the Use virtual day for Process Flow component days of week option is selected for the Automation
Engine, tasks cannot be staged beyond 24 hours from the start of the virtual day.
Warning: Staging tens of thousands of tasks can affect Backlog performance.

When you stage a task, the value in its schedule's Next run date field will be updated to its next run.
Creating Multiple Schedules
You can create multiple schedules for these Jobs that use different prompt values. For example, you might create
the following schedules:
• WORKDAY: Runs Monday through Friday at 9:00 A.M. and lists all Process Flows and Jobs for 8 hours without
including hour/minute schedules.
• EVERY_HOUR: Runs every hour and lists all Process Flows and Jobs including hour/minute schedules.

Managing Staged Tasks

Staged Jobs and Process Flows in the Backlog are shown in a DATE PENDING status as shown in the image
below. Components of a Process Flow in DATE PENDING status will show one of the following statuses:
• STAGED: The component will stay in a staged status until its Process Flow is initiated.
• STAGED_PW: The component has been staged and is waiting for one or more predecessor requirements to
be met. It will not be eligible to run until its parent Process Flow is initiated and its predecessor requirement are
met.
• STG SKIP: The component is part of a Process Flow but is not eligible to run. This happens when a day of the
week is unchecked or a skip Calendar is selected in the Schedule box on the component's General sub-tab.
 Applications Manager 9.4.1

For a description of all task status values, see Task Status Values.
You can filter staged tasks in the Backlog using the Future Hours field for a Backlog & History filter. For more
information, see Filtering the Backlog and History.
Editing Staged Tasks
Staging tasks in the Backlog gives you the opportunity to alter a task's details before it runs. Editing staged tasks is
exactly the same as editing any other non-running task in the Backlog. For information on altering task details, see
Viewing and Editing Task Details.

Working with Agents and Queues

You can monitor and manage Agents and Queues from the Explorer window. You can add, edit, or delete Queues
and Thread Schedules from the Object Admin menu.
 Applications Manager 9.4.1

Queues control the flow of tasks. All tasks must pass through an Applications Manager Queue to be executed. You
control Queue throughput by assigning a Queue to a Thread Schedule. You can define an unlimited number of
Queues.
Agents are instances of Applications Manager; an Agent is installed on each machine where tasks are executed.
An Agent can be an Automation Engine's Local Agent, or a Remote Agent. The Automation Engine is also listed
along with the Agents in the Explorer window. The Automation Engine schedules and controls task execution on all
the Agents assigned to it.
You monitor and manage Agents and Queues from the Explorer window.
Monitoring and Managing Agents
From the Explorer window, you can:
• View information in the Agent Summary including the status of the Automation Engine and Agent(s). An Agent
Summary is shown below.

• View tasks by Automation Engine, Agent, or Agent Group.

• View Agents by machine.
• Start, stop, idle, or resume the Automation Engine and/or Agent(s).
• Reset an Agent in a BUSY or TROUBLE status to display a STOPPED status if you do not want its status to
affect the status bar.
• Assign Thread Schedules to the Automation Engine and Agent(s).
• View and print Automation Engine and Agent log files.
• Rollover the log file for the AgentService process.
Activating/Inactivating Agents
When an Agent is not active, the status of the Agent is INACTIVE. All tasks in the Backlog and newly submitted
tasks to the Agent will move to History with a status of INACTIVE. You activate or inactivate an Agent by checking
or unchecking the Active box in that Agent's definition.
Monitoring and Managing Queues
From the Explorer window, you can:
• View information about all Queues in the Queue Summary. A Queue Summary is shown below.
 Applications Manager 9.4.1

• View tasks by Queue.

• Activate or inactivate multiple Queues.
• Change a Queue's priority.
• Assign Queues to Thread Schedules to control the number of threads the Queue reserves and the number of
tasks it can run concurrently.
Defining Queues
Queues are created using the Queues window. For detailed information, see Defining Queues.

Monitoring Agents
You can view an Agent Summary by clicking the Agents icon from the object tree.
Agents are installed on each machine where tasks are executed.
 Applications Manager 9.4.1

Each Automation Engine has one Local Agent and can control numerous Remote Agents and application Agents.
Several Agents are defined and the Remote Agent TRUNK is selected in the image above. From the Explorer
window you can view:
• An Agent summary by clicking the Agents icon in the object tree.
• All Agents on a machine by clicking the machine name under the Machines icon in the object tree.
• Agent status based on icons in the Explorer tree and descriptions in the Agent Summary.
Column Descriptions for the Agent Summary
The Agent Summary displays the status of each Agent. The columns are described below.
• Agent
Name of the Agent, Agent Group, or Automation Engine.
• Status
 Applications Manager 9.4.1

Current status of the Agent. For information on possible status values, see Automation Engine/Agent Status
Values .
• Type
Designates each listing as an Automation Engine or Agent type.
Although the Automation Engine and its Local Agent are defined as a single object in Applications Manager,
they are listed separately in the Agent Summary, and separate actions can be taken on them.
• Elapsed
Elapsed time of the Agent status.
• CPU
Percentage of CPU usage on the Agent machine. The CPU usage is updated about once every minute for each
Agent and the Automation Engine. CPU percentages are rounded to the nearest five percent.
• Max Tasks
Number of threads available for the Agent.
• Bklg
Number of tasks in the Backlog.
• Run
Number of tasks RUNNING.
• Hold
Number of tasks on HOLD.
• Abtd
Number of tasks ABORTED in the Backlog.
• Process Flow
Number of Process Flows in the Backlog.
You can customize many tables in Applications Manager, including the Agent Summary. When customizing tables,
you determine:
• Which columns are listed.
• What each column is named.
• How each column is displayed.
Your Applications Manager administrator can set default values for tables. Therefore, the columns in the Agent
Summary may be different from what is described above. For more information, see Customizing Tables .

Managing Agents
You manage the Automation Engine and its Agents in several ways. From the Explorer window you can:
• Take an action on a single Agent or Automation Engine by right-clicking an Agent's icon in the object tree or by
right-clicking a listing in the Agent Summary.
• Take an action on one or more Agents or the Automation Engine by highlighting them in the Agent Summary
and right-clicking.
• Take an action on all Agents and the Automation Engine by right-clicking the Agents icon in the object tree.
• Take an action on all Agents on a machine by right-clicking the machine name under the Machines icon in the
object tree.
• Change an Agent or Automation Engine's Thread Schedule by right-clicking the Agent or Automation Engine.
Actions you can take on Agents are start, stop, idle, resume, and reset. These actions can be taken on the
Automation Engine as well. Each action is described below.
 Applications Manager 9.4.1

To manage Agents, you must have the Take Actions on Agents User Option assigned to you by your Applications
Manager administrator.
Idling and Resuming Agents or the Automation Engine
If you want to stop processing newly submitted tasks through an Agent you can idle it. The Agent will go to an Idled
status and the icon for the Agent will be displayed with a yellow triangle over it in the Explorer tree. Tasks in the
Backlog set to run on an Agent in an Idled status will have a task status of AGENT WAIT. To take the Agent out of
the idle status, you resume it.
Starting Agents or the Automation Engine
Starting an Agent will start processes on that Agent if they are stopped and change the Agent's status to Running.
The Agent may change to an interim Starting status before it moves to Running. Starting an Agent is equivalent to
issuing the startso <Agent name> command. It may take some time to update the status when starting Agents or
the Automation Engine.
 Applications Manager 9.4.1

Stopping Agents or the Automation Engine

You should generally idle Agents rather than stop them if you want to stop processing tasks on a particular
machine. Stopping an Agent will put it into a Stopped status, but it will not stop any processes. If an OAE or
PEOPLESOFT Agent is stopped, Applications Manager won't poll the application for task status updates. Stopping
an Agent is equivalent to issuing the stopso <Agent name> command. It may take some time to update the status
when stopping Agents or the Automation Engine. When stopped, Agents show a Stopped status and the icon for
the Agent in the Explorer tree is gray. Tasks in the Backlog set to run on an Agent in a Stopped status will have a
task status of AGENT WAIT.
Showing BUSY or TROUBLE Agents as Stopped by Resetting
There are times when the machine where an Agent is installed is taken down for maintenance. When this happens,
the Agent will go into a BUSY or TROUBLE status in the Applications Manager client. If you know why the Agent is
in one of these statuses, and there is no need for action, you may not want the Agent's status to affect the color of
the status bar. You can right-click it and choose Reset from the pop-up menu. Resetting an Agent only changes its
viewable status to Stopped. The reset Agent will have no effect on the status bar.
Changing Thread Schedules for the Automation Engine and its Agents
Automation engine and Agent Thread Schedules set the maximum number of concurrent tasks that can run
through any combination of Queues. To change an Automation Engine or Agent's Thread Schedule, right-click the
Agent icon and select Threads from the pop-up menu. Applications Manager displays the Threads window shown
below where you select a Thread Schedule.

Thread Schedules are assigned to Automation Engines, Agents, and Queues. You can also specify a local or
Remote Agent's Thread Schedule in its definition. For information on defining Thread Schedules, see Defining
Thread Schedules.

Viewing and Printing Automation Engine and Agent Logs

The Automation Engine and Agent logs in the log directory are the primary source of information used for
diagnosing database and network connection errors, and for checking Agent status. The log directory also contains
server, import, install, and Applications Manager executable logs.
 Applications Manager 9.4.1

Viewing Automation Engine/Agent Logs

To view the process logs for an Automation Engine or Agent from Explorer:
1. Right-click on the Automation Engine or an Agent and select View Log from the pop-up menu.
Applications Manager opens the Agent logs window. All logs will be displayed for the selected Agent. Only
RmiServer.log files will be displayed for the Automation Engine.
2. Select the log you wish to view.
You can limit the list using the Search field or by selecting a log type from the drop-down list.
3. Click the View button.
 Applications Manager 9.4.1

The log will display in the File Viewer window. For detailed information using the File Viewer window, see
Viewing Output Files with the File Viewer.
Printing, FTPing, and Emailing Logs
To print, FTP, or email a log file without opening the file viewer, select a task and select an option from the Print
menu or one of the Print icons. For more information on printing output, see Printing, FTPing, and Emailing Output
Files.
Zipping Log Files
You can zip log files to compress them by selecting the file and clicking the Zip button. When the file is zipped, you
will still be able to view it from the Applications ManagerFile Viewer window.
You cannot zip current log files that are still receiving information.
Rolling Over AgentService.log and RmiServer.log Files
You can roll over the current file to create new AgentService.log files for Agents or the RmiServer.log files for the
Automation Engine. To rollover one of these logs, right-click on an Agent or Automation Engine and select Agent
Log Rollover or RmiServer Log Rollover. You might want to rollover a log file when debug is turned on and you
want to isolate what is written in a log.
Customizing the Agent Logs Table
You can customize many tables in Applications Manager, including the table in the Agent logs window. When
customizing tables, you determine:
• Which columns are listed.
• What each column is named.
• How each column is displayed.
Your Applications Manager administrator can set default values for tables. Therefore, the columns in the Agent
logs window may be different from what is shown above. For more information, see Customizing Tables.

Monitoring Queues
You can view the Queue Summary in Explorer.
Controlling the load on your system is critical. In Applications Manager, you control the workload by setting the
number of concurrent tasks that can pass through the Queues.
 Applications Manager 9.4.1

Viewing the Queue Summary

You can view Queue status based on icons in the Explorer tree and descriptions in the Queue Summary. To view
a Queue Summary, select the Queues icon from the object tree. Applications Manager displays a list of Queues in
the upper right pane as shown in the image above.
Column Descriptions for the Queue Summary
The Queue summary displays the status of each Queue. The columns are described below.
• Queue
Name of the Queue.
• Status
 Applications Manager 9.4.1

Displays whether the Queue is active or inactive. Active Queues apply the thread settings. When you inactivate
a Queue, no tasks will be processed through it. The tasks will remain in the Backlog with a QUEUE WAIT status
until the Queue is activated.
The object tree icons for inactive Queues will be covered by a yellow triangle.
• Pri
The priority assigned to the Queue. Priority defines the order in which the Queue is scanned for task initiation.
Tasks in a higher priority Queue will be processed before tasks in a lower priority Queue. The lower the number
you assign to a Queue, the higher priority it will have to run tasks. If all threads in a high priority Queue are
being used, Applications Manager will process tasks in lower priority Queues until the maximum number
of threads is reached. You can control the load on your system and the availability of computing resources
by giving careful thought to how you prioritize Queues and set their thread limits. For information on Queue
priorities, see Administering Queues .
• Threads
Number of threads assigned to the Thread Schedule displayed in the Schedule column.
• Bklg
The number of tasks in the Backlog waiting to run on the Queue.
• Schedule
The Thread Schedule assigned to a Queue. Thread Schedules control the maximum number of concurrent
tasks that can run through the Queue at any given time. For information on defining Queues and Thread
Schedules, see Administering Queues .
You can customize many tables in Applications Manager, including the Agent Summary. When customizing tables,
you determine:
• Which columns are listed.
• What each column is named.
• How each column is displayed.
Your Applications Manager administrator can set default values for tables. Therefore, the columns in the Queue
Summary may be different from what is described above. For more information, see Customizing Tables.

Changing Queue Settings

You can control the number of tasks that flow through a Queue in several ways:
• Select a Thread Schedule for the Queue based on the Min Thread and Max Thread values.
Minimum threads ensure that you always have a specified number of 'standby' threads available for priority
'rush' tasks. Maximum threads control the maximum number of tasks that can run concurrently in the Queue.
For more information on Thread Schedules, see Defining Thread Schedules.
• Set a priority for each Queue.
 Applications Manager 9.4.1

Changing Queue Settings

To change a Queue's settings, select the Queue, right-click, and select Change from the pop-up menu as shown in
the image above. Edit the fields using the information provided below.
• Name
This non-editable field displays the name of the Queue.
• Thread Schedule
The Thread Schedule controls the maximum number of concurrent tasks that can run through the Queue and
the number of threads that are reserved for the Queue at any given time. For more information, see Defining
Thread Schedules.
• Priority
Defines the order in which each Queue is scanned for task execution if the maximum number of threads for an
Agent is reached. Queues are scanned starting with the number 1 and ending with 99.
Execution order of tasks within a Queue is determined by the priorities assigned to their Job definitions.
• Active
Click this checkbox to activate the Queue.
 Applications Manager 9.4.1

Active Queues apply the thread settings. When you inactivate a Queue, no tasks will be processed through it.
The tasks will remain in the Backlog with a QUEUE WAIT status until the Queue is activated.
You can also activate or inactivate one or more Queues from the Queue Summary by highlighting the Queues,
right-clicking, and selecting the appropriate option. When you change Queue settings from the Queue Summary,
the Queue definition is altered in the database.
Applications Manager User Groups allow you to edit Queues. If you cannot edit them, see your Applications
Manager administrator.

Administering Queues
You control the flow of tasks to servers by using Applications Manager Queues. All tasks pass through an
Applications Manager Queue to get to a server. You control Queue throughput by assigning each Queue to a
Thread Schedule. You can define an unlimited number and type of Queues.
Thread Schedules control the number of concurrent tasks that can run through a Queue. When you define a
Thread Schedule, you specify the number of threads, the minimum threads, and the start and stop times for the
schedule. A Thread Schedule can be divided into sub schedules, letting you change the number of threads for
different times of the day.

For example, you might assign only one thread from midnight to 6:00 A.M., four threads from 6:00 A.M. to 5:00
P.M., and two threads from 5:00 P.M. to midnight. This gives you the ability to fine-tune workloads on your system.
The diagram below shows several different Queues.
 Applications Manager 9.4.1

Queue 1 has zero threads from midnight to 8:00 A.M., three threads from 8:00 A.M. to 4:00 P.M., and one thread
from 4:00 P.M. to 23:59:59. Queue 2 has one thread from midnight to 8:00 A.M., and three threads for the rest of
the day.
When Threads Are Set to Zero
If the thread setting for a Queue is zero, any tasks scheduled to run through that Queue will not be launched. The
tasks will be displayed in the Backlog with a status of QUEUE WAIT.
For example, you can set threads to zero to prevent end-user submissions from overwhelming the system during
the working day. To do this, set up a Queue with a schedule that includes zero threads from 7 A.M. to 6 P.M., and
10 threads at all other times. End-users would be able to submit tasks into the Queue during the normal business
day, but the tasks would simply be held until 6 P.M. when the Queue opens up. This way, all tasks submitted during
one day could be run overnight and made available the following day.
Selecting Minimum Threads with Thread Schedules
You can assign a minimum thread value to a Thread Schedule. Any Queue assigned to a Thread Schedule will be
able to have at least that number of threads available in a 'standby' mode.
For example, QUEUE_A (shown below) is guaranteed to have two available threads regardless of any tasks
requested or scheduled in other Queues. If the total threads for the Agent is set to 10, that would mean a maximum
of 8 tasks could run at any time through all the other Queues.

Queue Priority Max threads Min threads Cumulative Running

QUEUE_A 1 6 2 2

QUEUE_B 1 7 1 3

QUEUE_C 2 8 3 6

QUEUE_D 2 8 1 7

QUEUE_E 3 10 0 7 3

QUEUE_F 3 10 0 7
 Applications Manager 9.4.1

Queues are grouped and run by priority. For example, in the table above you have two Queues in each of the
three priority levels (1, 2, 3). If the Agent Thread limit is set to 10, and the minimum thread limit is set to 2 for
Queue_A and 1 for Queue_B, that leaves only seven threads available to Queues with other priorities. Based on
the Queues used in the example table above, if Queue_F were the only Queue running tasks, only three tasks
would be allowed to run because seven min threads with a higher priority level are already reserved.

Defining Queues
You control the flow of tasks to servers by using Applications Manager Queues. All tasks pass through an
Applications Manager Queue to get to a server. You control Queue throughput by assigning each Queue to a
Thread Schedule.

Applications Manager User Groups control access to Queues. If you do not have access to them, see your
Applications Manager administrator.
Procedure
To add a Queue:
1. From the Queues Selector window, click New.
Applications Manager opens the Queues window shown above.
2. Complete the fields using the information in the following table.
• Name
The name may be up to 30 characters long.
• Thread Schedule
The Thread Schedule controls the maximum number of concurrent tasks that can run through the Queue and
the number of threads that are reserved for the Queue at any given time. For more information, see Defining
Thread Schedules.
• Priority
Defines the order in which each Queue is scanned for task execution if the maximum number of threads for
an Agent is reached. Queues are scanned starting with the number 1 and ending with 99.
The execution order of tasks waiting to run in a QUEUED status is decided in the following order:
1.1 Queue priority
2.1 Job priority
3.1 Start date and time
Therefore, if two tasks are waiting to run in different Queues, and those Queues have the same priority, the
Jobs' priority is checked. If Queue and Job priorities are the same, their start date and times are compared.
• Active
Click the Active checkbox to activate the Queue.
 Applications Manager 9.4.1

Active Queues apply the thread settings. When you inactivate a Queue, no tasks will be processed through
it. The tasks will remain in the Backlog with a QUEUE WAIT status until the Queue is activated.
Editing Queues in Explorer
Applications Manager operators with the necessary User Group access can alter Queue definitions from Explorer.
For more information, see Changing Queue Settings.

Defining Thread Schedules

A Thread Schedule is assigned to each Applications Manager Queue. Thread Schedules determine the number of:
• Minimum reserved threads for a Queue.
• Maximum threads that can run concurrently through a Queue.
You can divide a Thread Schedule to cover different time periods during a day. For example, during normal work
hours you may want to limit a Queue to two concurrent tasks, then in the evening reset the Queue to 10 concurrent
tasks. Each Thread Schedule must cover the full 24 hours in a day.

Applications Manager User Groups control access to Thread Schedules. If you do not have access to them, see
your Applications Manager administrator.
Procedure
To define a Thread Schedule:
1. From the Thread Schedules Selector window, click New.
Applications Manager opens the Thread Schedules window shown above.
2. Enter a name and description for the Thread Schedule on the General tab of the Thread Schedules window
shown in the image above.
Note that there is one entry in the table on the General tab.
 Applications Manager 9.4.1

3. If you wish to specify times to set specific minimum and maximum threads, click New.
Applications Manager opens the Thread Schedule details window where you can specify the details for each
entry in your schedule.
4. Complete the fields on the Thread Schedule details window using the information in table below and click OK.
• Start Time
The start time for this entry (hh:mm).
• Stop Time
The stop time for this entry (hh:mm).
• Min Thread
The number of the Automation Engine's threads you wish to reserve for a Queue. The values can range
between 0 and the maximum number of threads available on the Automation Engine. If one or more
minimum threads are assigned to a Queue's Thread Schedule, then even higher priority Queues (Queues
with a lower number set in their Priority field) will have this many fewer threads available to them. This is
even true when no tasks are running in the Queue that is reserving the threads.
• Max Thread
The maximum number of tasks that can run concurrently in the Queue. The value can be between 0 and
9999. If you set the value to 0, the Queue will not accept any tasks during the time period specified. Tasks
assigned to this Queue will show a QUEUE WAIT status.
Only tasks in a RUNNING status count toward the Max thread setting.
Applications Manager adds a new entry to the table with the values you specified. You can add as many entries
to the table as needed to set different minimum and maximum values for different times of the day.
Updating and Deleting Thread Schedule Entries
To update or delete a Thread Schedule entry, select the entry in the table and select Edit or Delete.
Selecting Thread Schedules for Agents
You can select a Thread Schedule for an Agent to specify the maximum number of concurrent tasks that can run on
that Agent at one time in all Queues.

Removing External Predecessors by Queue

If you want to remove a Job or Process Flow header's external predecessors on insert to the Backlog, you can
assign it to the REMOVE_EXT_PREDS_ON_INSERT Queue. The predecessors will not be shown in the task
details or evaluated. If components in a Process Flow that is assigned to the REMOVE_EXT_PREDS_ON_INSERT
Queue have internal or external predecessors, they are evaluated normally.
It does not matter how the REMOVE_EXT_PREDS_ON_INSERT Queue gets assigned to the Job or Process Flow.
It can be:
• The default Queue of the Job or Process Flow definition.
• Assigned in a schedule.
• Selected for an ad hoc request on the Submit window.
If a task is inserted into the Backlog in the REMOVE_EXT_PREDS_ON_INSERT Queue, and you reassign it to
another Queue, the external predecessors are still removed. You cannot change a task's Queue from any other
Queue to the REMOVE_EXT_PREDS_ON_INSERT Queue.
Creating the REMOVE_EXT_PREDS_ON_INSERT Queue
The REMOVE_EXT_PREDS_ON_INSERT does not ship with Applications Manager. If you wish to use it you can
create it by hand or run an Applications Manager import and select REMOVE_EXT_PREDS_ON_INSERT. The
REMOVE_EXT_PREDS_ON_INSERT.exp file ships in the import directory.

Forecasting Jobs and Process Flows

With the Forecast, Graphical Forecast, and Production Schedule features, you can view Process Flows and their
components in the Backlog and History and view a list of scheduled Jobs and Process Flows.
Viewing Forecasts and Graphical Forecasts
 Applications Manager 9.4.1

Using the Forecast feature, you can view a list of scheduled Jobs and Process Flows. An example forecast is
shown below.

You can view a graphical forecast of scheduled Jobs and Process Flows. Graphical forecasts are displayed in
the Forecasted Gantt view window shown in the image below. For more information on graphical forecasts, see
Viewing Graphical Forecasts.
The data displayed in forecasts is generated and loaded into Applications Manager by running the FORECAST
Job. When you create a schedule for the FORECAST Job, you determine the time frame of the forecast and how
often it is run. For more information on running the FORECAST Job, see Setting the FORECAST Job Parameters.

Running a Production Schedule

 Applications Manager 9.4.1

You can get a more detailed look at tasks that are scheduled to run by generating a production schedule. An
example production schedule is shown below.

Skip {Process Flow}Report Name

---- ----------------------------------------------------
Saturday Feb 23 2002 00:00
{SYSTEM}Saturday Feb 23 2002 00:00
{SYSTEM}DELDEFAULT
NDOW {SYSTEM}HISTORY_PURGE

Monday Feb 25 2002 00:00

{SALES_REPORTS}Monday FEB 25 2002 00:30
{SALES_REPORTS}REGION_A
B If CURRENT TIME > 06:00:00 then SKIP TASK
{SALES_REPORTS}REGION_B
B If CHECK FILE NO /reports/region_b.dat
{SALES_REPORTS}REGION_C

Viewing Forecasts
The Forecast window shows you a list of scheduled Jobs and Process Flows.
Procedure
To open the Forecast window shown above, do one of the following:
• Open the Activities menu and select Forecast.
• Select the Forecast icon from the toolbar.
Applications Manager displays a list of forecasted Jobs and Process Flows shown below.

Each scheduled Job/Process Flow includes the start date and time and the Job or Process Flow's name. Process
Flows also include a key icon used to expand or collapse them.
To view the Jobs within a Process Flow, click the Process Flow's key. To expand all keys for a Process Flow and its
children, select the Process Flow, go to the View menu and select Expand Process Flows. To expand the keys in
all Process Flows, choose Expand All. To print or preview a forecast, use the print buttons.
 Applications Manager 9.4.1

Viewing Predecessors in a Forecast

Process Flow components are listed based on the execution order of each tasks' predecessors. If you want to
view their Process Flow's structure, right-click a component and select Graphical Predecessors from the pop-up
window. Applications Manager displays a flow diagram for the predecessors as shown below.

You can also select Predecessor Statement to only view the predecessor statement(s) for a Job, Process Flow, or
Process Flow component as shown below.

Running the FORECAST Job

 Applications Manager 9.4.1

Data displayed in forecasts is generated and loaded into Applications Manager by running the FORECAST Job.
When you create a schedule for the FORECAST Job, you determine the time frame of the forecast and how often it
is run. For more information on running the FORECAST Job, see Setting the FORECAST Job Parameters.

Viewing Graphical Forecasts

The Forecasted Gantt view window shows you a list of scheduled Jobs and Process Flows in a Gantt chart
format.

Procedure
To open the Forecasted Gantt view window shown above.
1. Do one of the following:
• Open the Activities menu and select Graphical Forecast.
• Select the Graphical Forecast icon from the toolbar.
Applications Manager displays the Forecast filter window shown below.

2. If you wish to filter the tasks displayed in the Forecasted Gantt view window, edit the options described below.
 Applications Manager 9.4.1

Field Limits the display of data from the FORECAST Job

to:

Start date Tasks scheduled after this start date.

End date Tasks scheduled before this start date.

Sub levels Process Flow components within a maximum nested

depth.

Include minute and hour Not include tasks that are scheduled by minutes or
hours (when unchecked).

Data displayed in the Forecasted Gantt view window is generated and loaded into Applications Manager by
running the FORECAST Job. When you create a schedule for the FORECAST Job, you determine the time
frame of the forecast and how often it is run. For more information on running the FORECAST Job, see Setting
the FORECAST Job Parameters.
By entering information into the fields on the Forecast filter window, you are filtering beginning with the next
scheduled task and ending with the last scheduled task loaded by running the FORECAST Job. You cannot
enter a date/time beyond the setting from the last run of the FORECAST Job.
The Forecasted Gantt view window will not include any tasks that are currently in the Backlog, even if the
tasks are staged. For more information on staging tasks, see chapter Staging Tasks in the Backlog.
3. Click OK.
Applications Manager displays a small animated window as the tasks are loaded for the Forecasted Gantt view
window.
Applications Manager displays the graphical forecast in the Forecasted Gantt view window. For information on
reading Gantt windows, see Reading the Gantt View Window.
4. If you wish, you can right-click a task and select Graphical Predecessors to view its predecessor links in a flow
diagram.
Gantt Legend
The legend describes the graphics used in the Gantt view windows. To display the legend, click the Legend button
in the menu bar. The Legend includes some symbols not used on the Forecasted Gantt view window. To close the
Gantt Legend window, click the X in the title bar.

Setting the FORECAST Job Parameters

The data displayed in a forecast is generated and loaded into Applications Manager by running the FORECAST
Job. When you create a schedule for the FORECAST Job, you determine the time frame of the forecast and how
often it is run.
 Applications Manager 9.4.1

Depending on your organization's needs, you can schedule this Job to run every day, or several times each day.
Additionally, if you want to set the forecast on an ad hoc basis, you can submit the Job as shown below.
 Applications Manager 9.4.1

The FORECAST Job includes the following prompts.

• Start Date Time
The start date and time for the forecast. The default value for the prompt is a series of numbers created using
the #aw_now Substitution Variables. They represent the current date and time. In the image above, the default
value is 20090211105811. This translates to:
• Year: 2009
• Month: February (02)
• Day of month: 11th
• Time: 10:58:11 A.M.
• End Date Time (default is 1 day past start date)
The end date and time for the forecast. If no value is entered for this prompt, the default value is 24 hours past
the start date. You can enter a different date using the same format as the Start Date Time prompt.
Hint: Cut and paste the number from the Start Date Time field and modify.
• Max Depth
 Applications Manager 9.4.1

The levels of sub Process Flows you wish to show in the forecast.
• Minimum Schedule Units
Select whether you want to limit the forecast to list tasks by day, hour, or minute.

Generating Production Schedules

If you want to see a report of all Jobs and Process Flows that are scheduled to run between specified dates, you
can run the PRODSCH Process Flow. The Process Flow runs two Jobs: SCHCREATE and SCHPRINT. The output
for the SCHPRINT Job reports the tasks by date and time. It includes the following information:
• The date and time each Job and Process Flow is scheduled to run
• The name of each component in each Process Flow
• The conditions associated with each component
The report can show only the tasks that will run, or all tasks that will run and all tasks that are eligible to run but will
not run due to conditions defined for the Job or Process Flow. The sample production schedule report shown in
this topic displays two Process Flows: SYSTEM and SALES_REPORTS. The Skip column in the analyst's report
displays an abbreviation indicating why the Job will not be run. Notice that NDOW displays for HISTORY_PURGE.
Process Flow names are in {braces}. Job names follow the Process Flow names. The SALES_REPORTS Process
Flow runs three Jobs: REGION_A, REGION_B, and REGION_C. The first two Jobs each have a BEFORE
condition.
Generating a Production Schedule
To generate a production schedule report:
1. Request and submit the PRODSCH Process Flow and enter the start and end dates.
2. Choose Yes or No for the analyst's status values.
Choose Y to show all tasks including those that will not run due to the days of the week settings and conditions.
This is useful for analysts that are reviewing schedules to make sure they will do what was intended. Choose N
to display only those tasks that will run. This report is most useful for operators who are monitoring the system.
3. Enter the minimum schedule number.

To display Use this value

Tasks scheduled to run daily -3

Tasks scheduled to run hourly -4

Tasks scheduled to run on minute intervals -5

If selecting an interval other than -3, you should review your start and end dates because the shorter interval
settings will produce larger reports.
4. Submit the Job and view the output for the SCHPRINT Job.
Sample Production Schedule

Skip {Process Flow}Report Name

---- ----------------------------------------------------
Saturday Feb 23 2009 00:00
{SYSTEM}Saturday Feb 23 2009 00:00
{SYSTEM}DELDEFAULT
NDOW {SYSTEM}HISTORY_PURGE
Monday Feb 25 2009 00:00
{SALES_REPORTS}Monday FEB 25 2009 00:30
{SALES_REPORTS}REGION_A
B If CURRENT TIME > 06:00:00 then SKIP TASK
{SALES_REPORTS}REGION_B
B If CHECK FILE NO /reports/region_b.dat
 Applications Manager 9.4.1

{SALES_REPORTS}REGION_C

Production Schedule Output Abbreviations

The five abbreviations used in the Skip column of the production schedule are described below.

Abbreviation Definition

NACT Not active

NDOW Not run, day of week

SONNHD Skip, not in Calendar (being run using a Calendar and it

is not in the Calendar)

RONHD Run, in Calendar (being run using a Calendar and it is

in the Calendar)

SONHD Skip, in Calendar (skip using a skip Calendar)

Monitoring and Managing Tasks with the Gantt View

The Backlog Gantt view window displays the contents of the Backlog in a Gantt chart format. It is real-time and
updated based on the Explorer Refresh Seconds setting. All actions that can be taken against tasks in the Backlog
can be taken against tasks in the Gantt view.

The Backlog Gantt view window displays an expandable task tree on the left, and the Gantt chart on the right. You
can change the size of the two panes by dragging the vertical splitter bar that divides the panes.
Each task (Job or Process Flow) is displayed on its own row. Rectangles represent the expected run times of the
tasks: black for Process Flows and blue for Jobs. Arrows drawn between the rectangles indicate predecessor links.
 Applications Manager 9.4.1

Displaying the Gantt View

To open the Backlog Gantt view window shown above, do one of the following:
• Open the Activities menu and select Backlog Gantt view.
• Select the Backlog Gantt view icon from the toolbar.
Applications Manager displays a small animated window as the tasks are loaded for the Backlog Gantt view
window.
Finding Tasks in the Gantt View
You can find a task in the Backlog Gantt view window by going to the Actions menu and selecting Find. Regular
expression searches help you find Jobs and Process Flows by name. For more information, see Finding Tasks in
the Gantt View Window.
Gantt Legend
The legend describes the graphics used in the Gantt view. To display the legend, go to the Actions menu and click
the Legend.
Taking Actions on Tasks and Viewing/Editing Task Details
You can right-click tasks in the Backlog Gantt view window to take actions on them or to view or edit their task
details the same way you would in the Explorer window. For more information on taking actions on tasks, see
Taking Actions on Tasks in the Backlog. For more information on viewing and editing task details, see Viewing and
Editing Task Details.
Displaying Gantt Task Summaries
When you are working in the Backlog Gantt view window, a pop-up menu is displayed when you hover over a task
as shown below. You can customize the information displayed in this menu by selecting Tables from the Options
menu and picking the Gantt task summary option. For more information, see Customizing Tables.
 Applications Manager 9.4.1

Reading the Gantt View Window

The Gantt view provides a good deal of information about the tasks running in the Backlog. The Gantt view window
displays tasks in chronological order with time displayed horizontally.

Process Flows
Process Flows are represented by a rectangle with a black border. The rectangle extends from the scheduled start
time to the scheduled completion time based on the average run time for the Process Flow. The average run time is
based on the sum of the average run times of all tasks in the Process Flow.
When a Process Flow is initiated, a green bar is displayed in the rectangle. The green bar indicates the current
run time for the Process Flow. The green bar is displayed until the Process Flow completes or is killed. When a
Process Flow completes, the run time bar turns black.
If a task in a Process Flow aborts, a red X is placed over the Process Flow name in the task tree. Note a Process
Flow never aborts, only the components in a Process Flow.
From an operations standpoint, you can display only the unexpanded Process Flows in the Gantt chart and easily
monitor the system. If a problem arises with a Process Flow, or you want to see more details about individual
components in a Process Flow, you can expand the Process Flow.
Jobs
Jobs are represented by a rectangle with a blue border. The rectangle extends from the scheduled start time to the
completion time based on the average run time for the Job.
Actual run times for Process Flows and Jobs are represented by solid bars running through the center of the
rectangles. The color of the bar indicates the status of the task.

Bar Color Description

No color bar Task is waiting to run.

Green Task is running.

 Applications Manager 9.4.1

Bar Color Description

Yellow Task is on hold.

Red Task has aborted.

Black Task has completed successfully.

Adjusted Start and End Times

Adjusted start and end times for Process Flows and Jobs are represented by the Start and End symbols. Before
the time a task is scheduled to run, these symbols will align with the start and end times of a Process Flow or Job.
If a Process Flow or Job starts earlier or later than scheduled, these symbols move to reflect the difference in times.
For a complete discussion of the adjusted start and end times, see Interpreting Adjusted Start and End Times.
Displaying Predecessor Links
You can display predecessor links for a task in the Gantt view by hovering the mouse pointer over the task's bar in
the Gantt chart as shown below.

Interpreting Adjusted Start and End Times

Adjusted start and end times show you calculated start and end times based on the current information available to
Applications Manager.
The Gantt view represents planned start and end times with rectangles: black for Process Flows, blue for Jobs. If
a Process Flow or Job is running ahead or behind schedule, the adjusted start and end times are indicated by the
symbols shown below:
• Adjusted start time:
• Adjusted end time:
Process Flow Examples
 Applications Manager 9.4.1

To help you interpret the start and end time symbols as they relate to Process Flows, several examples are given
below.

When a Process Flow is: The bar looks like this:

Waiting to run and is still on schedule

Waiting to run and is expected to start ahead of

schedule

Waiting to run, but is behind schedule

Running on schedule

Running ahead of schedule

Running behind schedule

Job Examples
To help you interpret the start and end time symbols as they relate to Jobs, several examples are given below.

When a Job is: The bar looks like this:

Waiting to run and is still on schedule

Waiting to run and is expected to start ahead of

schedule

Waiting to run, but is behind schedule

Running on schedule

Running ahead of schedule

Running behind schedule

Finding Tasks in the Gantt View Window

The Find feature of the Backlog Gantt view window allows you to easily find any task in the Backlog. Regular
expression searches help you find Jobs and Process Flows by name.
 Applications Manager 9.4.1

Procedure
To find a task in the Backlog Gantt view window:
1. Go to the Actions menu and select Find.
Applications Manager opens the Find component window shown above. The Find component window lists
all Jobs and Process Flows alphabetically. Process Flow components including sub Process Flows are listed
starting with their initial parent Process Flow.
You can enter a valid UNIX regular expression in the Search field to have Applications Manager filter the list of
tasks. In the image above, .*DAT is entered in the Search field to limit the list of tasks to ones with the letters
'DAT' in their name.
2. Select a task from the Find component window.
Applications Manager highlights the task in the Backlog Gantt view window.

Setting the Gantt View Preferences

You can customize the Gantt chart by selecting the options under the Preferences menu.
Keep History
When selected, this option will keep completed Process Flows in the Gantt view. Normally, completed Process
Flows are not displayed in the view. The Process Flows will remain in the Gantt view until you close the Gantt view
window.
Show Horizontal Lines
When selected, this option displays horizontal lines across the Gantt view.
 Applications Manager 9.4.1

Show All Predecessors

When selected, predecessor links are shown at all times.
Show Only Selected Predecessors
When selected, you must select a task from the tree to show its predecessor links.
Show Predecessors When Dragged Over
When selected, you must drag the mouse over a task's bar in the Gantt view to display its predecessor links.

Printing from the Gantt View

Using the commands under the Print menu on the Gantt view window, you can set page options, preview the
printed chart, and print the chart.
Page Setup
The Page Setup command will display a dialog similar to the one shown below. Use this dialog to set the paper
size, orientation, and margins.
 Applications Manager 9.4.1

Print Preview
The Print Preview command displays the dialog shown below. You can print directly from this dialog if you wish.
 Applications Manager 9.4.1

Print Gantt
The Print Gantt command displays the standard Windows print window shown below where you can set various
output options.
 Applications Manager 9.4.1

Automation Engine/Agent Status Values

The possible Agent status values are listed, along with a description of the status and a suggested course of action.

Status Description/Action

BUSY Description: The Automation Engine died abnormally.

The Automation Engine and/or Agent(s) may go
into BUSY status from time to time when there is
high Applications Manager activity or the system is
experiencing high loads. An Agent might also go into a
BUSY status if the file system is full.
Action: If the Automation Engine/Agent(s) stay in
BUSY statuses for extended periods when the system
load is low and the Applications Manager activity is low,
the logs of each should probably be reviewed for any
exceptions. Also, check to see if the RMI server process
is running. If the RMI server is not running, look at the
Automation Engine log file before restarting.

CHECK LOG Description: The Automation Engine or an Agent has

an error.
Action: Check the Automation Engine or Agent's log file
for detailed information.
 Applications Manager 9.4.1

Status Description/Action

CPU WAIT Description: The Automation Engine or Agent does

not have enough CPU capacity available to process
additional tasks. The CPU capacity is set for the
Automation Engine and each Agent with the CPU Limit
setting.
Action: Task will be processed as soon as there is
available CPU capacity.

Unavailable Description: An Agent encountered an error while

running.
Action: Look at the Agent log files in log directory.
Check the files for errors and verify that all parameters
are set correctly for the Agent.

IDLED Description: The Agent is running but not processing.

Action: To allow processing to continue, right-click the
Agent and select the Resume option.

INACTIVE Description: The Agent is inactivated; all tasks will go

to History with an INACTIVE task status.
Action: To set tasks to run normally again, check
the Active field in the Automation Engine or Agent
definition.

MGRSTOPPED Description: The Agent processes of a Java Agent

have been stopped by the AgentService process.
Action: You can restart the Java Agent from Explorer,
or from the command line by issuing the startso
<Agent name> command.

No_Service Description: The AgentService process is down and

the Agent has been stopped.
Action: Restart the Agent from the command line.

Running Description: The Automation Engine or Agent is

presently executing on the system.
Action: No action is required.

START_ERROR Description: The process necessary to run tasks could

not be launched.
Action:Check that there are adequate system
processes and disk space where Applications Manager
is installed. Also, check for adequate disk space in the
/temp directory. Check ulimit to ensure that the User
account does not have a process limit assigned to it
(UNIX only).

START_FAILED Description: The Agent did not get a response

indicating that a task was launched successfully (no
Process ID was returned).
Action: Possible error with pm file. Check that there
are adequate system processes and disk space where
Applications Manager is installed. Also, check for
adequate disk space in the /temp directory (UNIX only).
 Applications Manager 9.4.1

Status Description/Action

STARTING Description:The Automation Engine or Agent is

starting on the system. This is an interim status that will
change to RUNNING.
Action: No action is required.

Stopped Description:The Automation Engine or Agent is

stopped. This does not mean that RmiServer,
AgentService or any other process is stopped, only
that the thread for the Automation Engine or Agent is
stopped.
Action: You can restart the Automation Engine or
Agent from Explorer, or from the command line, by
issuing startso <Agent name> for an Agent or startso
<Automation Engine> for the Automation Engine.

Srvc_Down Description: The AgentService process went down

while the Agent was running.
Action: Stop and restart the AgentService process
with a startso agentservice command from the
command line.

TROUBLE Description: Set by the Automation Engine when

it decides that the Agent is not doing its task (for
example, the Automation Engine sent it a task to start
5 minutes ago, but the Agent never started it). The
so_back_process.so_last_activity has not been
updated for the amount set in the Sleep time field + 60
seconds.
Action:
Check the following:
• Make sure the RMI server is running.
• Automation engine: Locked row in database. May
need to run listpids.sql to find any hung Oracle
processes and stop them.
• Agent: Verify that there is adequate disk space.
• Look at the Automation Engine and Agent log files
in log directory. Check the files for errors and verify
that all parameters are set correctly for the Agent.
• Look into system CPU and memory usage for other
processes that might be impacting Applications
Manager operation.

Unavailable Description: An Agent encountered an error when

starting up.
Action: Look at the Agent log files in log directory.
Check the files for errors and verify that all parameters
are set correctly for the Agent.

Task Status Values

The possible task status values are listed, along with a description of the status and a suggested course of action.
Statuses that are unique to a particular extension are described in that extension's documentation. Be aware, too,
that statuses may be renamed by some condition actions and run time scripts.
 Applications Manager 9.4.1

Status Description/Action

ABOR-DB ERROR Description: The task aborted, then in a condition, an

error occurred causing a DB ERROR status change.
Since the task already completed, the status was set to
the first few letters of that completion status (i.e. ABOR)
plus a hyphen and DB ERROR.
Action: See DB ERROR status.

ABORTD Description: The task has terminated in an

unsuccessful manner on the Agent. This is an
interim status that will change almost immediately to
ABORTED.
Action: Wait for the status to change to ABORTED.

ABORTED Description:Applications Manager has processed the

task and it terminated unsuccessfully.
Action: To see why the task aborted, check the system
output file and view/edit the task details in the Backlog.

AGENT WAIT Description: The task is assigned to an Agent that

does not have enough threads or CPU available to
process the task.
Action: The task will be processed as soon as there
are available threads/CPU capacity. If this status occurs
often, you may want to change the Thread Schedule
assigned to the Agent.

BAD BATCH Description: There is no defined application

information for BATCH registered in Applications
Manager.
Action: Define a BATCH Application.

BAD CONDITN Description:A SQL statement or check file BEFORE or

AFTER condition has returned an error in the task.
Action: Edit the conditions and/or their SQL statements
for the task in the Backlog and in the Job/Process Flow
definition. Make sure you have sufficient tablespace
where applicable.

BAD CONNECT Description: The Host Login and password

combination that is specified for the task is in error.
Action: Check the Login and password assigned to the
Job or Process Flow component.

BAD DATE PRM Description:The date format required by the argument

type is incompatible with the prompt.
Action: Check the dates entered for a prompt if one
exists, or check the dates passed to a prompt or
condition by a Substitution Variables.

BAD LIBR Description:The Library associated with this Job

includes a path that cannot be found.
Action: Edit the Library's path.
 Applications Manager 9.4.1

Status Description/Action

BAD LOGIN Description:The Login specified for the task is invalid.

Action: There may be a database problem. Check
with your DBA to make sure the correct Database ID is
specified in the Job definition.

BAD MJN Description:The task's Job sequence number is

incorrect and does not match the currently registered
Job known to Applications Manager.
Action: Have your DBA check the Applications
Manager database to see if there is a bad entry in the
so_job_table table.

BAD MODULE Description: A bad Job name was entered for a

REQUEST JOB action in a condition.
Action: Edit the condition that generated the entry in
the Backlog.

BAD QUEUE Description: A condition with the CHANGE QUEUE

action has been met. The designated alternate Queue,
however, does not exist in Applications Manager.
Action: Edit the condition that generated the entry in
the Backlog.

BAD SQL STMT Description: A SQL statement associated with a

dynamic Substitution Variables used by this task is
incorrect.
Action: Dynamic Substitution Variables can be used
in prompts and conditions. Check what Substitution
Variables are used in the prompts and conditions for
this Job or Process Flow.

BAD TYPE Description: The data type specified for the task is
incorrect.
Action: Check the data type definition assigned to the
prompt.

BAD_AGENT Description: The Agent assigned to the Job does

not exist. This status will only occur if the Agent was
defined through a direct entry into the Applications
Manager database.
Action: Select an Agent for the Job.

CANCELLED Description: A condition on this task, or on a previous

component in the Process Flow, has cancelled the
remaining Process Flow components.
Action:Check the conditions specified in the
components of this Process Flow.

CONDITN WAIT Description: The task is waiting for a condition to be

met before executing.
Action: No action is required. You can check the
conditions for this task in the Backlog.
 Applications Manager 9.4.1

Status Description/Action

DATE PENDING Description: This task is not yet ready to run. Tasks are
not ready to run if:
• They have been staged by running either the
STAGING or STAGING_BY_SCHEDULE Jobs and
selecting prompts.
• Someone post-dated the start date/time for a Job or
Process Flow when requesting it.
• A condition with a DELAY TASK action prohibits the
task from running.
Action: No action is required. The task will run when its
reaches its start date and time, or when its conditions
allow it to. You can edit the task details of the Job or
Process Flow in the Backlog.

DB ERROR Description: An internal database error has occurred

while processing this task. Possible causes include:
• Subvars in prompts or conditions that use SQL have
returned an error when run from the command line,
such as SQL with a bad database link.
• The inability of the Applications Manager processes
were unable to connect to the Automation Engine's
database (network problems).
• A database or database server crashed.
Action: Try resetting the task—if that works, then
the error was resolved prior to the reset. Useful
troubleshooting information can be found in the
following locations:
• The system output file (viewable from the Output
Files tab of the Task Details window).
• The comments (viewable from the Comments tab of
the Task Details window).
• The AgentService and RmiServer process logs in
the log directory.

DEAD Description: The process associated with this task

can no longer be found on the host system. This is an
interim status that will change almost immediately to
DIED.
Action: Wait for the status to change to DIED.

DELETED Description: The task has been deleted from the

Backlog.
Action: Find out why the operator deleted the task and
resubmit the task if necessary.

DIED Description: The process associated with this task can

no longer be found on the host system. This happens
if a process takes more than five minutes to begin
execution after initiation. Usually there is a problem with
the Agent that prevents the task from executing.
If the task's status is still RUNNING at the time that the
process disappears from the host system, the task may
have been killed from the operating system.
Action: Check to see if the Agent is running. Check to
see if the task was killed from the operating system.
 Applications Manager 9.4.1

Status Description/Action

ERRORS Description: If you see this status in the Backlog,

Applications Manager detected an error in a condition.
You may also see listings for the RMI server or your
Agents in History with an ERRORS status. These are
informational only. For more information, see the status
of your Automation Engine and Agents.
Action: To see why the task with a bad condition went
into this status, check the system output file and view/
edit the task details in the Backlog.

FILE ERROR Description: The tmp file could not be created.

Action: Check that the disk is not full or for improper file
and directory permissions.

FIN-DB ERROR Description: The task finished, then in a condition, an

error occurred causing a DB ERROR status change.
Since the task already completed, the status was set to
the first few letters of that completion status (i.e. FIN)
plus a hyphen and DB ERROR.
Action: See DB ERROR status.

FINISHED Description: The task has successfully completed its

operation.
Action: No action required.

HOLD Description: The task has had its execution delayed

indefinitely because:
• The task has a condition with a HOLD TASK action.
• The Hold Task box was checked for a Job/Process
Flow that was requested on an ad hoc basis.
• The task in the Backlog has been put on hold.
Action: The task will remain on hold until the status is
changed by an action associated with another condition
or by a User.

HOLD PRED WT Description: The task is on hold and is waiting for one
or more predecessor requirements to be met.
Action: The task will not be eligible to run until both of
the following occur:
• The hold status is changed by an action associated
with another condition or by a User.
• The predecessor requirements for the task are met.

HOST FAILURE Description:An error occurred when the host attempted

to execute the command required to perform the task.
This usually indicates a lack of process slots on the
system or an inadequate sub process limit for the
Applications Manager account.
Action: Check with your Applications Manager
administrator.

INACTIVE Description: This task was skipped because the

Active option in its Job, Process Flow, or Agent
definition is unchecked.
Action: No action required.
 Applications Manager 9.4.1

Status Description/Action

INITIATED Description: One or more of the components in

this Process Flow have been initiated and all the
components in the Process Flow have not yet finished.
Action: No action required.

KILL Description:A request to terminate the task while it was

executing on the host was issued by a User or by an
action associated with a condition. This is an interim
status that changes almost immediately to KILLED.
Action: See the explanation for the KILLED status.

KILL1 Description: Used by the OAE extension when the

Automation Engine is evaluating a task that is being
killed. When the Agent successfully kills the task, it
sets the task's status to KILL. The Automation Engine
evaluates any post-processing conditions and sets its
status to KILLED.
Action: See the explanation for the KILLED status. If
you wish, you can resubmit the task.

KILLED Description:Applications Manager has processed the

task after a request for termination has been made for
it. The task has therefore been removed from the host
system.
Action: If the task is still in the Backlog, you can reset
it.

KILLING Description: Used by the OAE extension when the

Automation Engine has sent the command to the Agent.
When the Agent successfully kills the task, it sets
the status to KILL. The Automation Engine evaluates
any post-processing conditions and sets the status to
KILLED.
Action: See the explanation for the KILLED status. If
you wish, you can resubmit the task.
 Applications Manager 9.4.1

Status Description/Action

LAUNCH ERR Description: The Automation Engine had an error

launching the task. Possible causes include:
LAUNCH ERROR
• Oracle errors when launching the task
• Machine disk space issues
• Machine performance issues, or network issues
(such as a hung port, network slowness, or firewall
changes)
With regard to network issues, LAUNCH ERR can
mean that the task start command didn't reach the
Agent (Automation Engine-->|Agent), or it can mean
that the Agent didn't respond back (Automation Engine|
<--Agent).
Action: Before calling Broadcom support, check the
following for errors:
• Task's comments (in the Backlog or History, right-
click the task and go to Comments)
• Unregistered task log files on the machine. Check
in the out directory on the machine where the task
was supposed to run. It may have started running,
but couldn't register the output.
• The RmiServer.<time stamp>.log file in the
Automation Engine's log directory. This file may
include errors starting with AwE.
• The latest AgentService log files for the local or
Remote Agent. These may include errors starting
with ERR.
If you find errors, search for them in the Knowledge
Base on the Broadcom Support Web site or call
Support. Before contacting Support, have the log files
listed above ready to send.

LAUNCHED Description: The task has been launched, but its status
has not yet been determined.
Action: No action required.

MAX RESTARTS Description: The task has been restarted 99 times.

This is the maximum number of times a task can be
restarted.
Action: To run the task, delete and resubmit.

MGRSTOPPED Description: This status is displayed only in History. It

is associated with the Agents. It indicates the date and
time the AgentService process stopped.
Action: No action required. This is only a historical
record.

Min Run Time Description: The task finished more quickly than the
time specified in the Min run time field of the Job's
definition. Applications Manager developers specify a
min run time when they expect a Job to run for at least
the time they specify.
Action: Investigate why the task finished so quickly.
 Applications Manager 9.4.1

Status Description/Action

NO PRIORITY Description: This task has been scheduled with a

priority of zero. Since no priority has been assigned to
the task, it cannot be executed until a priority is set.
Action: Change the priority for the task in the Backlog
and/or edit the Job/Process Flow definition.

PRED WAIT Description: The task is waiting for a predecessor

requirement to be met before executing.
Action: No action required. Predecessors can be edited
for the running of a task in the Backlog if the task is in a
non-running status.

PW-DELETE Description: The component in a Process Flow

was waiting for a predecessor requirement to be
met before executing and it has been deleted. The
component remains in the Backlog as a placeholder for
predecessor inheritance.
Action: No action required.

PW-SKIP Description: The task was waiting for a predecessor

requirement to be met before executing and it has been
skipped.
Action: No action required.

QUEUE WAIT Description: The Job is assigned to a Queue that does

not have enough threads available to process the task.
Action: The task will be processed as soon as there is
an available thread. If this task should be running, make
sure that:
• The Queue has not been inactivated.
• The Thread Schedule assigned to the Queue has
an adequate number of threads in its Max run
time setting to allow the appropriate number of
concurrently running tasks.
Queue definitions can be altered from the Explorer
window or from the Queues window.
You can change the Queue for the particular running of
a task in the Backlog on the Task Details window.

QUEUED Description: The task has been sent to an Applications

Manager Queue, but has not been processed by the
Automation Engine to determine execution eligibility.
The status should quickly be updated.
The execution order of tasks waiting to run in a
QUEUED status is decided in the following order:
1. Queue priority
2. Job priority
3. Start date and time
Therefore, if two tasks are waiting to run in different
Queues, and those Queues have the same priority, the
Jobs' priorities are checked. If Queue and Job priorities
are the same, their start dates and times are compared.
Action: No action required.
 Applications Manager 9.4.1

Status Description/Action

RECURSIVE Description: The components within this Process Flow

are recursive, calling one another in an infinite loop.
This only happens in Process Flows that were created
in a previous Applications Manager version.
Action: Edit the Process Flow to change its
components' predecessor requirements.

RESV THRDS Description: The Job's Queue has reserved threads

but none are available.
Action: The task will be processed as soon as there is
available threads.

SELF WAIT Description: The Single run option is set for the Job
or Process Flow, and there is another instance of the
task running. The first must complete before the second
instance will be initiated.
Action: No action required. If you want to allow two
instances of the task to run concurrently (even within
a Process Flow), uncheck the Single run option in the
Job/Process Flow definition.

Skip!Active Description: This Process Flow component was

skipped because ioption is unchecked.
Action: No action required.

Skip!DayofWk Description: This Process Flow component was

skipped because the corresponding day of the week
was not assigned to it.
Action: No action required.

Skip!RunCal Description: This Process Flow component was

skipped because a run Calendar assigned to it did not
include this day.
Action: No action required.

SkipCal Description: This Process Flow component was

skipped because a skip Calendar including this day was
assigned to it.
Action: No action required.

SkipCond Description: The task will not be run because an action

associated with a condition has specified that the task
be skipped.
Action: Check the conditions for the Job/Process Flow.
 Applications Manager 9.4.1

Status Description/Action

STAGED Description: This Process Flow component is part of a

Process Flow that has been staged. Tasks are staged
by:
• Running either the STAGING or
STAGING_BY_SCHEDULE Jobs and selecting
prompts.
• Post-dating the start date/time for a Job or Process
Flow when requesting it on an ad hoc basis.
The components will stay in a staged status until their
Process Flow is initiated.
Staged and post-dated Jobs and Process Flows in the
Backlog will be shown in a DATE PENDING status.
Action: No action is required. The task will run when
its reaches its start date and time. You can edit the task
details of the Process Flow or its components in the
Backlog.

STAGED HOLD Description: This Process Flow component is on hold

and has been staged.
Action: The task will not be eligible to run until both of
the following occur:
• The hold status is changed by an action associated
with another condition or by a User.
• The task reaches its start date and time.

STAGED_PW Description: This Process Flow component has been

staged and is waiting for one or more predecessor
requirements to be met.
Action: The task will not be eligible to run until both of
the following occur:
• The task reaches its start date and time.
• The predecessor requirements for the task are met.

STARTED Description: This status is displayed only in History.

It is associated with the RMI server or an Agent. It
indicates the date and time the RMI server or Agent
started.
Action: No action required. This is only a historical
record.

STG SKIP Description: This Process Flow component has been

staged and is being skipped in the Process Flow. This
happens when a day of the week is unchecked or a
skip Calendar is selected in the Schedule box on the
component's General sub-tab. When its Process Flow
runs, this task will move to History with a Skip!Active
status.
Action: No action required.
 Applications Manager 9.4.1

Status Description/Action

STG_PW HOLD Description: This Process Flow component is on hold

and has been staged and is waiting for one or more
predecessor requirements to be met.
Action: The task will not be eligible to run until all of the
following occur:
• The hold status is changed by an action associated
with another condition or by a User.
• The task reaches its start date and time.
• The predecessor requirements for the task are met.

STOPPED Description: This status is displayed only in History.

It is associated with the RMI server or an Agent. It
indicates the date and time the RMI server or Agent
stopped.
Action: No action required. This is only a historical
record.

TIMEDOUT Description: The Automation Engine has processed

the task after it has exceeded its permitted run-time
allotment.
Action: Determine why the task was taking so long to
run. If appropriate, change the maximum run time for
the Job, or change the task's conditions.

TIME-OUT Description: The task has taken longer than the

maximum run-time period specified in the Job definition
or a maximum run-time period specified in a condition.
This is an interim status that should change quickly to
TIMEDOUT.
Action: See TIMEDOUT for actions.

UNAVAILABLE Description: The required Agent is not running.

Action: Start the Agent.

UNKNOWN Description: The Agent cannot update the Automation

Engine for unusual reasons.
Action: Check the Agent log file for errors.

UNSAT-FINISH Description: Someone has removed this task as a

predecessor to all referenced tasks. The predecessor
links of other tasks need to be satisfied by another
running of this task. For more information, see
Unsatisfying Tasks as External Predecessors in History.
Action: No action required.

WARNING Description: an Applications Manager run-time

extension changed the status of a Job to WARNING.
Usually this status is assigned to a task that has errors
but has gone to completion.
Action: Check the log for the task to see what errors
occurred.
 Applications Manager 9.4.1

7 Development Guide
The Development Guide is a comprehensive procedures manual that covers all aspects of
Applications Manager development.
The Development Guide is a comprehensive procedures manual that covers all aspects of Applications Manager
development. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written within <brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

About This Guide

The Development Guide is a comprehensive procedures manual that covers all aspects of Applications Manager
development. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written within <brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Applications Manager Development

When we talk about development in Applications Manager, we are referring to the creation of Jobs to run tasks,
and the addition of Jobs to Process Flows. If you are a developer, you will most likely:
• Create Jobs to run programs and scripts.
• Create Process Flows to run a series of Jobs.
• Add dependencies to Process Flow components to establish the correct execution order in Process Flows.
• Define Job parameters.
• Add IF - THEN logic to Jobs and Process Flows to ensure the correct conditions exist before they execute.
 Applications Manager 9.4.1

• Automate retrieval of values from databases to eliminate data entry errors.

• Schedule Jobs and Process Flows to automate production.
Objects
As you build Jobs and Process Flows, you will use a number of objects including:
• Applications to categorize Jobs and Process Flows
• Libraries to specify paths to programs
• Program Types to interface with programs and applications
• Database and Host Logins
• Substitution Variables to store values used in Job parameters
• Queues to control load on your systems
• Output Devices to distribute output
There are many other objects that you may use, or that may be used by the Applications Manager administrator or
operators.
Naming Conventions
You should put some thought into naming conventions for your objects because you cannot readily rename objects
in Applications Manager. This is not a problem if an object is not used in very many places because you can copy
the object, give it a new name, then replace the old object with the new object. But if you have used the object in
many places, copying and replacing is not practical.
Replacing Scripts with Jobs and Process Flows
One of the greatest returns on your investment in Applications Manager can be realized by replacing your scripts
with Applications Manager Jobs and Process Flows. Long scripts that have been used to run nightly batch
processing can be broken up, and each program run by the script can be replaced by a Job. Those Jobs can then
be combined to create a Process Flow that duplicates, or improves, the Job flow in the original script. Elements in
the script that handle output should be replaced by Applications Manager Output Devices.
If the scripts require manual intervention by operators, every attempt should be made to use Applications
Manager predecessors, conditions, and Substitution Variables to automate these manual steps. Predecessors
and conditions can ensure that the Jobs in a Process Flow execute in the correct sequence and that the correct
conditions have been met for the tasks to execute successfully. Substitution Variables can be used to automatically
enter values for parameters where the values are retrieved from your corporate database at the time of execution.
These three features (predecessors, conditions, and Substitution Variables) give you the power to automate
operations to a greater extent than is possible with any other distributed scheduler.
Scheduling
Depending on the size of your organization, you may be responsible for scheduling Jobs and Process Flows, or this
responsibility may fall to production analysts. Either way, Applications Manager has an extensive set of features
for scheduling Jobs and Process Flows. You should be able to create schedules that closely match your corporate
data processing procedures.
Viewing Object Reports
Applications Manager comes with a set of predefined Reports that give you information about your Applications
Manager objects. You can also import an extensive set of Applications Manager History Analysis Reports that you
can use to review how tasks were processed through Applications Manager. You can also create your own custom
Reports.

Guidelines for Starting Out in Applications Manager Development

There are a number of different ways to get started with Applications Manager. If you are very organized, you
can begin by defining most of the objects you will use to build Jobs and Process Flows, then build the Jobs and
Process Flows. Or you can begin by building Jobs, and defining the other objects as you need them. How you
proceed is up to you. Both approaches will get you where you want to go. The basic steps you can use to begin
with creating Jobs are outlined below.
Step 1: Create Jobs
In Applications Manager, a Job runs a single program. To create a Job, you specify a Library, Application, Program
Type, program, Queue, Login, and Output Device. At the heart of the Job is the program or script it runs.
What Jobs do you need to create? A good starting point is to create a Job for each program in your existing shell
scripts. If you do not have shell scripts, create a Job for each program you want to run.
 Applications Manager 9.4.1

You define Jobs once, but can assign them to multiple Process Flows.
Step 2: Define Objects
As you define Jobs, you use a variety of simple and compound objects. A compound object is made up of one
or more simple objects. You can define objects as needed. Examples of simple and compound objects are listed
below.

Simple objects Compound objects

Applications Jobs

Libraries Process Flows

Program Types Queues

Data Types Output Groups

Step 3: Create Process Flows

After creating Jobs, you can combine them to create Process Flows. an Applications Manager Process Flow is
equivalent to a script that runs many Jobs. You can create schedules for a Process Flow as a whole, and also
specify eligibility settings for each component.
Step 4: Define Queues
All tasks submitted to your system from Applications Manager must pass through an Applications Manager Queue.
A Queue is a pipeline that can be used to control the flow of tasks to the server. By defining the appropriate set
of Queues, you can set a limit on the number of tasks that can be processed at any one time for different periods
during the day.
When you define a Queue, you assign the Queue a Thread Schedule. The Thread Schedule sets the number of
concurrent tasks that can be processed by the Queue. The number of tasks can be different for different times of
the day.

Starting Out with Existing Scripts

If you have been using scripts to run your operations, you can begin by taking one of the scripts and replicating
its functionality in Applications Manager. In Applications Manager, a Process Flow is equivalent to a script. Like a
script, a Process Flow runs one or more programs on a schedule. Unlike a script, Applications Manager lets you
pull together the necessary components from the Applications Manager database to create a Process Flow instead
of typing all the information into a long script. The function of a script that may have taken hours to write can now
be emulated in Applications Manager in a few minutes.
Below is a description of the steps you take to turn an existing script into an Applications Manager Process Flow.
Procedure
To take a script and turn it into an Applications Manager Process Flow:
1. Identify all the programs run in the script.
Programs might transfer files, load data, run reports, or run statistics.
2. For each program, create a Job.
With Jobs, you specify where the program is located, the name of the program, and where the output should be
printed.
If a program requires input, define a prompt for each parameter.
You can specify scheduling information for the Job or add it to a Process Flow. In this example, we will add it to
a Process Flow, which in turn will be scheduled.
3. Save each Job definition.
Each Job you have defined can be used in any number of Process Flows.
4. Create a Process Flow, adding the Jobs you created.
The Process Flow links the Jobs together and executes them in the order you specify. A Process Flow
accomplishes the same thing as a script.
5. If appropriate, add predecessor links and conditions under which each Job will execute.
 Applications Manager 9.4.1

6. Add scheduling information to the Process Flow by choosing the time and days you want the Process Flow to
run.
If appropriate, add scheduling eligibility to each component in the Process Flow.
7. Save the Process Flow.
After saving the Process Flow, Applications Manager will begin running it on its defined schedule(s).

Naming Convention Guidelines

The initial implementation will require the creation of a comprehensive set of naming convention guidelines for
Applications Manager objects, particularly Jobs, Process Flows, and aliases for Process Flow components.
The best practice recommendation is to build upon the familiarity of an existing naming convention, rather than
create a scheme entirely from scratch. An existing scheme provides welcome familiarity and can be expanded to
allow for new circumstances.
Naming Conventions That Work
The following are suggestions for Applications Manager naming conventions:
• Choose names that reflect the basic function of the object. The Job name FTP is very good.
• Strive for generic names rather than specific names. Using general names with general, utilitarian objects allows
you to use one object in many places, rather than having to build a new object for each different situation. Again,
FTP is a good name for a Job. COMPRESS_EXTENTS might be another.
• Login object names should take advantage of the commenting facility in Applications Manager to clarify
where the Login will connect and to help avoid identically named objects (which aren't allowed in Applications
Manager). For example, a Login object can be named 'fred@db1'. The @ symbol and all text after it are treated
as a comment by Applications Manager. For login purposes, only 'fred' is used as the user name.
• It is often more clear to those monitoring Applications Manager if Job and/or Process Flow names include some
type of ownership designator. For example, a Process Flow named NETBACKUP_OPS might be identified as
an operations group Process Flow.
• If creating Queues for each Application, the Queue can be named the same as the Applications.
Naming Conventions That Don't Work
The following are suggested things to avoid for Applications Manager naming conventions:
• Avoid existing naming conventions if they are clearly unworkable or create many names that are very similar in
appearance. For example, Process Flows called 'MMN200A', 'MNN200A', and 'MNM200A' can be very difficult
to distinguish between.
• Avoid adding any time qualifier to object names. For example, MONTHLY_TRANSFER may work fine for now
but what happens if the transfer frequency changes to daily or monthly? This would require a name change to
the object or defining another object with a new name. Just plain TRANSFER might be better.
• Do not name Jobs 'SCHED-<Process Flow name>', unless they are Process Flow requestor Jobs.
Using Department Designation Prefixes
We generally recommend that you avoid putting the same (obvious) prefix on the front of many object names (for
example, ORA_COPYFILE, ORA_MOVEFILE, and ORA_RMFILE). In a list of many objects, lots of names with the
same first few characters can be very difficult and slow to read.
Remember, these naming conventions are only suggestions. Although we suggest avoiding prefixes, some users
prefer to add Application (and Job/Process Flow designations) to their object names. For example, the name
AP_PF_PAYMENTS designates PAYMENTS as being part of the Accounts Payable Application, and a Process
Flow.
You can get around using these naming designations for Jobs and Process Flows by selecting Applications and
using J/P columns to sort lists on windows where Jobs and Process Flows are selected.

Adding, Editing, and Deleting Applications Manager Objects

You add, edit, and delete objects using the selector windows. The Queues Selector window is shown below.
To open a selector window, do one of the following:
• Select an icon from the toolbar on the desktop.
• Select an item from the Object Admin menu on the desktop.
• Select the icon next to an object's field when defining another object (see the Schedule field in the image
below).
 Applications Manager 9.4.1

Adding and Editing Objects

To add, edit, or delete an Applications Manager object:
1. Open the selector window that corresponds to the object you wish to add or edit.

Only the objects assigned to you via User Groups will be displayed in the selector window. In the image above,
the Queues Selector window is open.
The Jobs and Process Flows selector windows include an Application box. Applications specify a group of
Jobs and Process Flows. The Application you select determines which Jobs and Process Flows are listed in the
table. For more information on Applications, see Defining Applications.
Selector windows are not displayed on the taskbar because they do not contain unique information. For more
information on using the Applications Manager desktop, see the User Guide.
2. To update an existing object, select the object and click Edit. To refresh the list of objects on the selector
window, click Refresh.
You can type the first few letters of an object's name in the Search field, and Applications Manager will find it.
The Search field accepts valid UNIX regular expressions. For example, to search for all Jobs starting with the
letters A and T, you would enter [at] in the Search field. For more information on syntax accepted by regular
expressions, see Appendix A: Regular Expression Tables.
3. To define a new object, click New.
Applications Manager opens an object definition window. If you are defining a new object, the fields will be
empty except where defaults come preselected.
Required fields are marked with a '*' symbol to their right.
4. Enter values for the fields on the various tabs of the object.
When you enter or change a field value, Applications Manager displays a blue triangle next to the current tab's
label to signify unsaved changes. A red triangle signifies unsaved changes made to a sub-element of a tab. For
more information, see Updating Unsaved Changes.
If a supporting object is selected in another object's field, and a User does not have access to the supporting
object, that field will be grayed out. For example, assume the MONITOR Thread Schedule is assigned to the
BATCH Queue. A User named Pat has the BATCH Queue in an edit User Group, but she doesn't have the
 Applications Manager 9.4.1

MONITOR Thread Schedule in any User Groups. Pat can edit the BATCH Queue, but she cannot change its
Thread Schedule, because the field is grayed out for her (showing MONITOR as its selection).
5. If you wish, you can select the User Groups tab to assign the object to one or more User Groups. For more
information on assigning objects to User Groups, see the Administration Guide.
If you are assigned to a Maintenance user group, the object will automatically be assigned to your User
Group. You can view a list of objects that you have access to from the View menu by selecting View Assigned
Objects. If you do not have access to the object, see your Applications Manager administrator.
6. Select the appropriate button:
• To save the object's definition and close the window, click OK.
• To add/update the object's definition and keep the window open, click Apply.
• To close the window without updating the object's definition, click Cancel.
Deleting Objects
To delete an object, highlight the object in its selector window and click Delete. If the object you are deleting is
referenced by one or more objects, you must remove the references before it can be deleted. If you try to delete an
object without first removing the references, Applications Manager will display a message saying it is in use. For
information on viewing references for an object, see Viewing Object References.
If Jobs or Process Flows are in the Backlog, you cannot delete their definitions. You will need to wait until they
complete executing.

Copying Applications Manager Objects

There may be times when you want to create several Applications Manager objects that are similar except for a few
minor changes. For example, you may want to create two Jobs that run two different programs, but the information
for the programs is identical except for the program names.

Prerequisites
 Applications Manager 9.4.1

There are several prerequisites to keep in mind when copying Applications Manager objects:
• You must have edit access to the original object. This access is controlled by User Groups. If you created the
original object, you probably have edit access to it.
• You must have User Group access to all the User Groups that are assigned to the object.
• The object you want to copy must be displayed on its object type selector window.
If you are copying an object recently created by another User, it may not be displayed in the selector window. You
may need to refresh the display by clicking the Refresh button.
Copying Objects
To copy an Applications Manager object, select the object in its selector window and choose the Copy button.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
The EXPRESS Queue is selected in the Queues Selector window above. After you choose the Copy button,
Applications Manager opens the new object definition. To save the new object, give it a name (and description, if
required).
Since they are only a name and description, you cannot copy Output Groups.
Copying Jobs and Process Flows
When you copy a Job or Process Flow, the prompts are always copied. You have the option of coping its
conditions, documentation, and schedules.

To copy a Job or Process Flow:

1. From the Jobs or Process Flows selector window, highlight the Job or Process Flow you wish to copy.
2. Click Copy.
Applications Manager displays the Copy Job or Copy Process Flow window shown above.
 Applications Manager 9.4.1

3. Enter the name and description for the new Job or Process Flow.
4. Select the appropriate checkboxes to copy conditions, documentation, or schedules.
5. To accept the information and close the window, click OK.
Applications Manager closes the Copy Job or Copy Process Flow window, adds the Job or Process Flow to
the selector window, and opens the new Job or Process Flow's window.

Viewing Object Reports

To view Reports for an object type, open that object's selector window and click Reports.Applications Manager
comes with a set of Reports that provide information about the Applications Manager objects. You can also import
an extensive set of Applications Manager History Analysis Reports that you can use to review how tasks were
processed through Applications Manager. You can also create your own custom Reports. A Report that audits
schedule changes is shown below. Additional Reports may be created by Users if they have the necessary User
Group access. For information on creating Reports, the Administration Guide.

You can view Reports for each of the operations windows and selector windows.
 Applications Manager 9.4.1

To view Reports for: Do this:

An object type Open that object's selector window and click Reports.

An operations window Open the operations window and choose the Report
type from the Reports menu.

This opens the Reports window and selects the Report type that corresponds to the window you opened it from. In
the image below, the Reports button is selected on the Jobs Selector window, opening the Reports window with
the Jobs type highlighted.
To view Reports for another object type, select that object type from the Type box. If an object is not listed in the
Type box, there are no Reports for it. To view a Report, select it and click the Show button.

Enabling Audit Reports

To run Applications Manager auditing Reports, your Applications Manager Administrator must enable auditing for
the Automation Engine. For more information, see the Administration Guide.
 Applications Manager 9.4.1

Prompt Values
Some Reports require you to enter prompt values. If the Report you select requires prompt values, you must
respond to them in the Report Parameters window shown below. After entering the prompts, click OK and
Applications Manager will display the Report in its own window.

Changing the Lines per Page

You can specify the number of lines displayed on each page in a new window using the Lines per Page field. The
new setting will go into effect when you click the Redisplay button. Doing so will update the time and date in the
Report header. It will not recompile the SQL.
How Task History Report Data Is Generated
Data used in task history Reports is generated and loaded into Applications Manager by running the
CALC_HISTORY_STATISTICS Job. If a task history Report data does not seem current, it could be because this
Job has not run recently. For more information, see the Administration Guide.

Viewing Object References

Applications Manager is object-oriented: you can create an object once, then use it many times. For example,
you can create a Job and assign it to many Process Flows. If you wish to delete an object, you must remove its
references first. You can view all references for an object by selecting an object in a selector window and clicking
the Usage button as shown below.
 Applications Manager 9.4.1

To view or edit the definition a referenced object, select the object and click Edit.

Updating Unsaved Changes

When you enter or change a field value, Applications Manager displays a blue triangle next to the current tab's
label to signify unsaved changes. To save the changes and close the window, click OK. To save the changes and
keep the window open, click Apply.
 Applications Manager 9.4.1

In the Jobs window shown above, unsaved changes have been made on the General tab.
If you click Cancel, Applications Manager displays the window shown below. From this window you can click Yes to
discard the pending changes for the tabs listed, or No to remain on the tab in the object's definition.

Creating Jobs
A Job is the basic building block in Applications Manager. For each program you want to run (such as FTP,
application, or database load), you must create a Job. A Job specifies all the information required to run a program
including:
• General information: the task that will be run and its program information
• Execution options and output settings
• Prompts: information that is passed to the program as variables
 Applications Manager 9.4.1

Jobs can be run individually with a schedule or on an ad hoc basis from the Requests window. They also can
be run as a component of a Applications Manager Process Flow. The Jobs window is shown below with the
PROCESS_FLOW_REPORT Job displayed.

Requesting a Job from its Definition

You can request a Job from it's definition. This opens the Submit window, like the Request window does. This is
beneficial for testing changes you make to the object.
How Jobs Fit into Applications Manager
If you have been using scripts to run your operations, you have launched programs from within a script. In
Applications Manager, you create a Job to launch each program. After creating a Job, you can run the Job by itself,
or add it to a Process Flow. The image below shows the relationship between scripts, Jobs, and Process Flows.
 Applications Manager 9.4.1

Keeping with the Applications Manager object-oriented approach to operations, you can use a Job in as many
different Process Flows as you wish. If you change a Job definition, the change is applied to every Process Flow
that includes the Job. You do not have to change the definition in each Process Flow. This saves you a great deal
of time maintaining your system.
Related Chapters
This chapter focuses on the basics of creating a Job. For additional information, see the following:
• Working with Predecessors
• Adding Prompts to Jobs and Process Flows
• Working with Substitution Variables and Replacement Values
• Working with Conditions
• Scheduling Jobs and Process Flows

Defining Jobs
To add a Job to Applications Manager, go to the Object Admin menu on the desktop and select Jobs.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Jobs. If you do not have access to them, see your
Applications Manager administrator.
Jobs and Process Flows should not be edited while running the STAGING Job or executing exports and imports.
For Rapid Automation Agent documentation including Agent-specific Login object tabs, see the the following.
• The Banner Rapid Automation Agent for Local Clients Documentation
• The Banner Rapid Automation Agent for the Automic Web Interface Documentation
• All other Rapid Automation Documentation
Procedure
To add a Job to Applications Manager:
1. From the desktop, open the Jobs Selector window in one of two ways:
• Select the Jobs icon from the toolbar.
• Go to the Object Admin menu and select Jobs.
For more information, see Adding, Editing, and Deleting Applications Manager Objects.
2. From the Jobs Selector window, click New.
Depending on your configuration, you may need to select a Job type from the Select job type window shown
above. The Job type you select will determine the default selections for certain fields, such as the Program Type
and Login.
Applications Manager opens the Jobs window.
To create OAE or PeopleSoft Jobs, go to the Agents Selector window, select the appropriate Agent and use
the Aux button.
3. Define the Job by assigning values to the fields on the General tab. For more information, see Entering General
Information for Jobs.
4. If you wish, you can edit the information on the other tabs in the Jobs window at this time. For information on
each of the tabs of the Jobs window, see Using the Tabs of the Jobs Window.
 Applications Manager 9.4.1

5. Click Apply to add the Job definition to the list of Jobs, or OK to add the new definition to the list of Jobs and
close the Jobs window.
6. Applications Manager displays an error message to alert you to any required fields that have not been filled in.
Editing and Deleting Jobs
To edit or delete a Job, select the Job on the Jobs Selector window and select the appropriate button. For
information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
If a Job is used in one or more Process Flows, you must remove it before you can delete the Job. If a Job is used in
a Process Flow and you try to delete it, Applications Manager will display a message saying the Job is in use.
If a task for a Job is in the Backlog, you cannot delete it. You will need to wait until the task has completed
executing before you can delete its definition.

Using the Tabs of the Jobs Window

The Jobs window includes several tabs as shown below.

Some of the tabs are more commonly used than others. Additionally, the Process Flows window includes several
of the same tabs as the Jobs window. For these reasons, some tabs on the Jobs window are described in this
chapter and others are described in later chapters.
Job Tabs Discussed in this Chapter
The following tabs are discussed in this chapter:
• General: Specifies the name and description of the Job. It also tells Applications Manager where to find the
program or script the Job will run and how to run it. Many of the fields on this tab are required. For details, see
Entering General Information for Jobs.
• Execution Options: Determine what happens when a Job runs. For details, see Entering Execution Options for
Jobs.
• Output: Controls what happens to the output of the Job. For details, see Specifying Output Options for Jobs.
• Documentation: Provides a location to enter relevant information about the processing of a task. By selecting
an individual Job and choosing Documentation, operators can access these comments, suggestions, or
instructions for an individual task. For details, see Adding Job Documentation.
• User Groups: Controls access to the Job. User Groups can be added to a Job from the User Groups tab as
well as from the User Group itself. User Groups are usually defined by your Applications Manager Administrator.
For details, see Assigning User Groups to Jobs.
Job Tabs Discussed in Other Chapters
The following tabs are discussed in later chapters:
• Schedule: Creates schedules to run the Job. Schedules can be based on days of the week, specific days of
the month, and days in a Calendar. You create more than one schedule for a Job. For details, see chapter
Scheduling Jobs and Process Flows.
• Prompts: Pass arguments or parameters to a program or script. For more information, see chapter Adding
Prompts to Jobs and Process Flows.
• Predecessors: Specify external predecessor links for the Job. External predecessor links are dependencies
on other stand-alone Jobs, Process Flows, or Process Flow components. While predecessors are used in all
Process Flows, they are only defined for Jobs in special case scenarios. For details, see chapter Working with
Predecessors.
• Conditions: Conditions control the execution of tasks. They provide IF/THEN logic for your Job. Conditions
can be evaluated before, during, and after a task executes, or after a task is deleted. For details, see chapter
Working with Conditions.
 Applications Manager 9.4.1

Example: Creating a Job to Run an Existing Script

One of the main goals of Applications Manager is to get you out from under the burden of writing UNIX and
Windows scripts. However, we realize that you may have already invested a great deal of time writing scripts that
work well. You can run your existing scripts from Applications Manager quickly and easily. Then, as time permits,
you can convert the scripts to Applications Manager Jobs and Process Flows.
Pros and Cons of Running Existing Scripts
You can use Applications Manager to run your existing scripts by creating a Job for each script. You do not have to
make any modifications to the scripts. However, you lose many of the benefits of the Applications Manager object-
oriented approach to operations. The pros and cons of running existing scripts are outlined below.
Pros:
• You can get up and running with Applications Manager in a minimum amount of time.
• You can use some of the Applications Manager conditional features at the Process Flow level.
• You can capture standard out and standard error output and view it online.
Cons:
• You cannot restart Process Flows in the middle.
• You cannot use Applications Manager conditions to control the flow of components within a Process Flow.
• You lose the ease of maintenance because you still have to maintain scripts.
• You cannot capture output generated by programs run by the script unless that output is sent to standard out.
Example
Assume you have users who would like to view a listing of all the employees in your company by department. You
have a SQL script named employees.sql that allows you to do this. The SQL script is shown below:

>cat employees.sql
set verify off
set feedback off
set termout off
spool &so_outfile
column ename heading 'Employee|Name'
column dname heading 'Dept|Name'
select emp.ename, dept.dname
from emp, dept
where dept.dname = '&dept_name'
and emp.deptno = dept.deptno;
spool off

When the variable dept_name is passed to the employees.sql script, it returns all the employees in that
department.
Creating the Job
The first step in creating a Job to run the employees.sql script is to define a new Job and fill in the information on
the Job's General tab. A sample Job named EMPLOYEES that runs the employees.sql script is shown below.
 Applications Manager 9.4.1

The specifics of all the fields on the General tab are discussed in later topics. For now, note that there is a
Program box that tells Applications Manager what to run. The path in the Location field is based on selections
made in each of the fields in this box Note that AWSQLP is selected in the Type field. This designates the Job as a
SQL*Plus Job.
Assigning a Login to the Job
Because SQL tasks need to access a database, a Database Login must be assigned to the Job on the Execution
Options tab as shown below.
 Applications Manager 9.4.1

Applications Manager Logins give users access to a database or Host Login without requiring that they know the
password.
Adding a Prompt to the Job
To allow users to pass a dept_name variable to the employees.sql script, you need to add a prompt to the Job as
shown below.
 Applications Manager 9.4.1

The prompt above uses the Dept_Name data type to pass a value to the dept_name variable. The Dept_Name
data type includes a SQL statement that allows users to select a single entry from a list of departments.
Good to Go
With the required fields completed on the General, Login, and Execution Options tabs, the Job is ready to run
from the Requests window. It can also be added to a Process Flow object.

Entering General Information for Jobs

For a Job to execute a program, you must provide information about the program on the General tab of the Jobs
window shown below. This information tells Applications Manager where to find the program the Job will run and
how to run it. Fields marked with an '*' to the right are required.
 Applications Manager 9.4.1

You can define certain objects by clicking the icon to the right of their field. Applications Manager will display the
selector window where you can define the new object. For example, you can click the Application icon to display
the Application selector window.
Entering Job Header Information
All values in the Job header are required. They are described below:
• Name
The name may be up to 30 characters long. Job names can include letters, numbers, periods, colons,
underscores, and hyphens. The first letter of a Job name must be a letter or number.
Do not name Jobs 'SCHED-<Process Flow name>', unless they are Process Flow requestor Jobs.
• Description
The description may be up to 100 characters long.
• Application
Applications are the general category to which Jobs and Process Flows belong (for example: inventory,
accounts payable). They are used on the Requests window to limit the list of Jobs and Process Flows. For
more information on defining Applications, see Defining Applications.
• Agent/Group
The Agent where the program will execute. This field allows you to select Agents and Agent Groups. To run the
Job on:
• A single machine defined as an Agent, select the Agent.
• Either of two or more Agents assigned to an Agent Group, select the regular Agent Group.
 Applications Manager 9.4.1

• All Agents assigned to an Agent Group, select the multi-execution Agent Group.
For information on which Agents are assigned to what groups, or which Agent Groups are multi-execution, see
your Applications Manager administrator.
When Agent Groups are assigned to Jobs, particular Agents may be specified for Process Flows, Process Flow
components, requests, or in schedules. For more information, see How Agent Assignments Are Handled for
Process Flow Components.
• Queue
The Job will run on this Queue even when added to the Process Flow, unless the Insert components into
process flow's queue Automation Engine option is set. For more information on setting Automation Engine
options, see the Administration Guide.
If the Job is run using a schedule and that schedule includes a Queue, that setting overrides the Job's Queue.
If the Job is submitted on an ad hoc basis, the User may have the option to change the Queue on the Submit
window.
• Single run
When selected, two instances of the Job cannot run concurrently. The second instance will show a status of
SELF WAIT until the first completes..
• Active
When selected, the Job will run when scheduled or included in another Process Flow and be available from the
Request window. If not selected, the Job will not run when scheduled or included in another Process Flow, and
it cannot be run from the Requests window.
• Stay in queue on abort
When selected, the aborted Job remains in the Backlog so it can be examined, repaired, and reset. The Queue
is not blocked by this aborted Job, unless the Queue has only one thread and the Allow aborted task to block
single threaded queue Automation Engine option is checked.
When this option is not checked, and the Job aborts and leaves the Backlog, it will satisfy any Success
predecessors it may have with other tasks. Failure and Failure (skip on success) predecessors will not be
satisfied.
If this option is not selected and the Job aborts, it leaves the Backlog and a record is written to History. The
Job may be examined from History to determine why it aborted, but because there is no longer a record in the
Backlog, it cannot be repaired or reset.
When this option is selected, and the Restart once on abort option is not selected, and the Job aborts, you will
see the original Run ID <run_id> in History and the current listing <run_id>.01 in the Backlog.
This setting can be overridden with a condition. This is most commonly done for Process Flow components.
Entering Program Information
In order for a Job to execute a program or run a Process Flow, you must define its program information in the
Program box on the General tab. Jobs created for some Applications Manager extensions such as OAE and
PeopleSoft may have different fields in their Program box than what is shown in the image above for standard
Jobs. For more information, see your Applications Manager extension documentation.
The Program fields for standard Jobs are described below:
• Library
The path to the program source or executable. The Program Type defined in the Type field may supply a
subpath. For information on defining Libraries, see Defining Libraries.
• Library path
This non edit field displays the path of the Library selected in the Library field.
• Program Type
This defines which type of program the Job will run, such as shell scripts, host command, or SQL*Plus.
Applications Manager comes with several Program Types already defined. For more information on defining
Program Types, see Defining Program Types.
• Program name
The name of the program that will be executed by the Job. Program names can be typed into this field, or
selected based on the Job's Agent, Library, and Program Type using the Select button. When you click the
Select button, Applications Manager displays a list of valid file names in the path defined by the Agent, Library,
 Applications Manager 9.4.1

and Program Type. If you use the Select button for a Job assigned to an Agent Group, you will be able to
search for the file on the Agent you select. If you type in a program name, Applications Manager does not verify
that it exists.
• Location
As you enter the program information, Applications Manager displays the path and file name in this non-editable
field.

Defining Applications
The Application field provides a way to assign Jobs as well as Process Flows to an organizational group. The
groups might be programs, machines, divisions, or some other characteristic. When editing or requesting Jobs and
Process Flows, you can select an Application and the Jobs and Process Flows displayed will be limited to those
that are assigned to the Application.

Applications Manager User Groups control access to Applications. If you do not have access to them, see your
Applications Manager administrator.
Procedure
To define a new Application:
1. From the Applications Selector window, click New.
Applications Manager opens the Applications window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Complete the fields in the Applications window using the information below.
• Name
The name may be up to 30 characters long.
• Description
The description may be up to 100 characters long.
• Notification
Optionally use Notifications to send messages and output files based on task status to email addresses or
any Output Device defined in Applications Manager. For information on defining Notifications, see Defining
Notifications.
• Environment Variables
Optionally specify one or more Environment Variables as a single Applications Manager object. For
information on defining Environment Variables, see Defining Environment Variables.
 Applications Manager 9.4.1

Defining Libraries
When you create a Job, you specify the location of the program or script to run on a host. The Library defines a
path, which will be the first part of that location. A subdirectory of the Library path can be specified when you select
a Program Type for the Job. You can use the same Library for Jobs that run on different operating systems by
specifying a path for each.

Applications Manager User Groups control access to Libraries. If you do not have access to them, see your
Applications Manager administrator.
Procedure
To define a new Library:
1. From the Libraries Selector window, click New.
Applications Manager opens the Libraries window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a Library name.
The name is a short identifier for the path.
3. Enter a path for one or more operating systems.
Library paths can be hard-coded or they can include Environment Variables. The advantages of using
Environment Variables are:
• The same variable can be defined with different paths on all Agents of a particular operating system.
• You can export and import Libraries and be assured that the Jobs using them will point to the right path in the
other Applications Manager instance.
When Environment Variables are used, you must define the variable for each Applications Manager Agent.
You cannot use Environment Variables that are defined with Applications Manager Environment Variable
objects.
For UNIX machines, define the variable at the end of the $AW_HOME/site/sosite file in Bourne Shell format. To
define a variable called INVERTORY_APP, you would enter:

INVENTORY_APP=/inventory/programs; export INVENTORY_APP

For Windows machines, define the variable at the end of site/envvar.bat as follows:

set INVENTORY_APP=\inventory\program

Modifying Libraries that Ship with Applications Manager

 Applications Manager 9.4.1

If you wish to modify one of the Libraries that ships with Applications Manager, create a new Library using the
Copy function. The Libraries that ship with Applications Manager will be overwritten each time you upgrade.

Defining Program Types

A Program Type defines how a program accepts input and handles output. Applications Manager comes with
several predefined Program Types (see chapter Program Type Descriptions.

Applications Manager User Groups control access to Program Types. If you do not have access to them, see your
Applications Manager administrator.
Multiple Operating Systems Supported
Each Program Type can support UNIX and Windows operating systems if the corresponding fields in the OS
portion of the General tab are completed. This eliminates the need to define separate Program Types for each
OS as required in previous versions of Applications Manager. In the example shown above, the same Program
Type script (host command) is used for all three operating systems, but the syntax used in the command paths are
different. Other interfaces might require different scripts for each OS, and therefore different host commands.
Procedure
To define a new Program Type:
1. From the Program Types Selector window, click New.
Applications Manager opens the Program Types window.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
 Applications Manager 9.4.1

2. Fill in the fields described below.

• Name
Name of the Program Type. Field length: 10 characters.
• Description
Description of the Program Type. Field length: 30 characters.
• Param format
Describes the format of data passed to the Applications Managerpr file, and therefore the program. Usually
#v=#d, or #d, where #v = variable and #d = value.
If you use #v in the format, you have to enter the variable names when you define prompts for the Job. If
you use only #d in the format, you do not have to enter the variable names. The variables are passed to the
program in the order they are created, and the program reads them sequentially and identifies them by their
order in the command.
• Login type
Specifies the Login type for Jobs run with this Program Type. If a Login type is selected, it will be displayed
in the Login type non-editable field on the Login tab of the Jobs window for all Jobs that use this Program
Type. Only Logins with a corresponding Login type selected in the Type field of their definition will be
available. If you pick 'No Selection', all Logins will be available on the Execution Options tab for Jobs that
use this Program Type. For more information on assigning Logins to Jobs, see Entering Execution Options
for Jobs.
• Output Scan
Scans output for text strings. Depending on the rules of the Output Scan, the Job will fail or succeed when it
is found. For information on defining the rules of an Output Scan, see Defining Output Scans.
• Notification
Optionally use Notifications to send messages and output files based on task status to email addresses or
any Output Device defined in Applications Manager. For information on defining Notifications, see Defining
Notifications.
• Environment Variables
Specifies one or more Environment Variables as a single Applications Manager object. For information on
defining Environment Variables, see Defining Environment Variables.
• Required logins
These options allow you to force users to select a Login when defining Jobs that use this Program Type. If
Primary is selected, users must select a primary Login for Jobs using this Program Type before they will be
allowed to save the Job definition. If Both is selected, they must also select a secondary Login. For more
information on assigning Logins to Jobs, see Entering Execution Options for Jobs.
• Host command
Name of the Program Type script located in the exec directory on each Agent that supports the Program
Type. The Program Type script defines the method for passing input to the program and getting output from
the program.
• Command path
The subdirectory where programs of this type are stored. This field works in conjunction with the Library
defined for the Job. If you leave the field blank, Applications Manager will expect to find the program in the
directory specified in the Library field.
• File extension
Filters the programs in the specified directory by this file extension when you use the Select button for
the Program field on the Jobs window. File extensions defined for Program Types are not included in
the $program environment variable. When file extensions are required to initiate programs, they must be
included in the Program Type script. For information on defining Program Type scripts, see chapter Running
Custom Applications from Applications Manager .

Entering Execution Options for Jobs

By setting a variety of options on the Execution options tab shown below, you can control what happens when a
Job executes.
 Applications Manager 9.4.1

The Execution options fields are described below:

• Output Scan
Scans output for text strings. Depending on the rules of the Output Scan, the Job will fail or succeed when
strings are found. Output Scans are assigned to Jobs and Program Types. If a task has Output Scans defined in
both its Job and Program Type definitions, only the Job's Output Scan will be used. For information on defining
the rules of an Output Scan, see Defining Output Scans.
• Notification
Optionally use Notifications to send messages and output files based on task status to email addresses or
any Output Device defined in Applications Manager. For information on defining Notifications, see Defining
Notifications.
• Environment Variables
Specifies one or more environment variables as a single Applications Manager object. For information on
defining Environment Variables, see Defining Environment Variables.
• Priority
 Applications Manager 9.4.1

Determines when this Job runs in relation to other Jobs waiting in the same Queue if the maximum number
of threads are occupied for the Queue. A Job with a lower numbered priority will run before Jobs with higher
numbers. The top priority setting is 1, and the bottom is 99. The default is 50. The Job will use this setting when
run by itself or when added to a Process Flow.
Jobs submitted with 0 priority will have the status of NO PRIORITY in the Backlog and will not run.
The execution order of tasks waiting to run in a QUEUED status is decided in the following order:
• Queue priority
• Job priority
• Start date and time
Therefore, if two Jobs are waiting to run in different Queues, and those Queues have the same priority, the Jobs'
priorities are checked. If Queue and Job priorities are the same, their start date and times are compared.
• Max run time
Used to prevent runaway programs. It determines how long the program can run before timing out
(DDD:HH:MI). If a task times out, Applications Manager aborts the task and gives it a status of TIMEDOUT. The
default time is 00:00:00, which lets the task run forever.
• Min run time
Used to flag tasks that run in a shorter time than expected (DDD:HH:MI). If a task completes in less than the
minimum run time, Applications Manager aborts the task and gives it a status of Min Run Time. The default time
is 00:00:00 which effectively inactivates this option.
• Ave run time
Stores the average run time for a Job (DDD:HH:MI). You can either manually enter a value in this field,
or run the AW_CALC_AVE_RUN_TIMES_1 Job to populate it. For more information, see Running the
CALC_AVE_RUN Job. This time will be displayed in the Gantt charts on the Backlog Gantt View, History
Gantt View, Graphical Forecast, and Process Flow Gantt View windows. For more information on the Gantt
chart, see chapter the Administration Guide.
• Keep system output
When selected, the system will store the system output from the Job. The output will be stored for the number of
days set in the Retention days field on the Job's Output tab. The output is useful for debugging tasks that have
aborted. If this option is not selected, only the report output file will be available.
• Restart once on abort
When selected, Applications Manager will automatically restart a Job the first time it aborts, but will not restart it
if it aborts a second time.
When this option and the Stay in queue on abort option are both set, and the Job aborts, you will see the
current listing <run_id>.02 in the Backlog to show the restarted Job. There will also be two records written in
History:
• The original listing for the Run ID <run_id> shows that the Job ran.
• The second listing <run_id>.01 shows that it aborted.
Login Settings
If Jobs will be running programs that require a login to a database, application, or host, you must assign Logins to
them. The primary and secondary Logins make it possible to supply two Logins to a Job. This is useful if a program
accesses two different databases. For example, a program might read from one database and write to another
database.
If the program run by a Job requires access to a database or server, you can set the Login the system will use
when the Job is executed.
The Logins available for a Job are limited to the type listed in the read-only Login type field. A Job's Login type is
determined by the Job's Program Type. The image below shows the Login tab for a Job named EMPLOYEES. On
the Login tab, ORACLE is listed in the Login type field. The Job gets the Login type from the AWSQLP Program
Type's Login type field. For information defining Program Types, see Defining Program Types.
 Applications Manager 9.4.1

For information defining Logins, see the Administration Guide.

This setting can be overridden for Jobs that are included in a Process Flow by selecting a Login in the Login field
on the Components tab. For information on assigning Logins to Process Flow components, see Setting Execution
Options.
Selecting Login Source Options
The following options control the Login Applications Manager uses when the Job is executed:
• Automation Engine Setting: Uses the option selected for the Automation Engine/Local Agent. The options
that can be selected for Automation Engine/Local Agent are Jobs' and Users'. If Automation Engine Setting
is selected here, and Jobs' is selected for the Automation Engine/Local Agent, Applications Manager uses
the Login(s) assigned on this tab in the Login ID fields for the primary and secondary Logins. If Automation
Engine Setting is selected here, and Users' is selected for the Automation Engine/Local Agent, Applications
Manager uses the Login assigned to the User.
• Job's Login: Uses the Login(s) assigned in the Login ID fields for the primary and secondary Logins.
 Applications Manager 9.4.1

• User's Login: Uses the Login assigned to the User (if one is assigned). This option is useful if you want to run a
report based on the User's view of a database.

Defining Output Scans

Some programs can complete, executing successfully, but not accomplish their intended work. For example, an
Oracle report may execute correctly, but return bad data. The only way to tell if the report content is correct is to
parse the report text. Output Scans are used for this purpose. Output Scans are Applications Manager objects used
to scan output for text strings that indicate if a task has failed or succeeded. Output Scanning supports .zip and
.pdf files.
Each Output Scan includes one or more rules. To use an Output Scan, you
• Define the Output Scan object.
• Add rules to the Output Scan.
• Assign the Output Scan to a Process Flow component, Job, or Program Type.
 Applications Manager 9.4.1

Creating an Output Scan

 Applications Manager 9.4.1

To add a new Output Scan:

1. From the Output Scan Selector window, click New.
Applications Manager opens the Output Scan window.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a name and description for the Output Scan.
3. After creating the Output Scan, add rules.
If you want the tasks associated with this Output Scan to fail if no rules are met, check the Fail If No Rule Met
box.
4. In the Fail Display Status field, enter the status name you want displayed if a task fails because no rules are
met and the Fail If No Rule Met box is checked.
Adding Rules to an Output Scan
To add a rule to an Output Scan:
1. From the Output Scan window, click the New button.
Applications Manager opens the Rule window.
2. Complete the fields in the Rule window using the information below.
• Text
The text string to search for in the specified output file(s). This field accepts regular expressions. For
example if you want to look for the words "TEST" and "FAIL" in either order you could search for TEST.*FAIL|
FAIL.*TEST.
Additionally, the following can be used:
• . stands for any single character.
• * stands for any number of the previous character.
Therefore:
• .* stands for any number of characters.
• | stands for the "or" connector.
• & stands for the "and" connector.
To include Substitution Variables or Replacement Values in the text search, click the { } button.
• Lines from End
Optionally allows you to specify to start the scan a number of lines from the bottom of the file. This is so you
can scan just the end of very long files.
• Match Case
The case of the text string in the Search Text field must match in the specified output file(s) when this option
is checked.
• Files
Specifies the output files to scan:
• System Output: Scans only the system output file.
• Other Output: Scans all registered output files, except the system output file.
• All Output: Scans all registered output files, including the system output file.
• Pattern Matching: Scans register files with names matching the pattern you specify. If you enter a pattern
that does not match any registered file names, no files will be scanned and no error will be returned.
This field allows regular expressions. For wildcard pattern matching, use the % character or .*. For
example, enter report% to specify all registered output file names beginning with report. To search for
two registered file names, create two rules.
• Action
Determines whether tasks fail or succeed when the text string in the Search Text field is found in the
specified output file(s).
• Display as
The task status displayed in the Status column in the Explorer window when the text string in the Search
Text field is found.
3. To save the settings and add the rule to the Output Scan, click OK.
 Applications Manager 9.4.1

Applications Manager adds the rule to the Rules table on the Output Scan window.
Rules are evaluated in the order they are listed. If a rule for an Output Scan evaluates to true, all remaining rules
are not evaluated. If you wish to reorder the rules, use the arrow buttons to the right of the list.
Copying Output Scan Rules
You can copy one or more rules from other Output Scans using the Copy button on the Output Scan window.
Order of Precedence
Output Scans can be assigned to Program Types, Jobs, and Process Flow components. When a task runs,
Applications Manager looks at its Program Type, Job, and Process Flow component assignments—in that order.
If specified, each Output Scan assignment will override the entire set of Output Scan rules specified by a previous
object.
For example, assume that you have defined the following objects as shown below.

In this example:
• Output Scans S1, S2, and S3, each with its own set of rules.
• Program Type SHELLS with the Output Scan S1 assigned to it.
• JOB_A and JOB_B each with the SHELLS Program Type and the S2 Output Scan assigned to them.
• JOB_C and JOB_D each with the SHELLS Program Type and no Output Scans assigned to them.
• FLOW_1 with JOB_A, JOB_B, JOB_C, and JOB_D assigned to it, and with the S3 Output Scan specified for
JOB_A and JOB_B's Process Flow component override settings.
The following Output Scan settings would be used:
• JOB_A would use S2 when run as a stand-alone task or S3 when run in FLOW_1.
• JOB_B would use always use S2.
• JOB_C would use S1 when run as a stand-alone task or S3 when run in FLOW_1.
• JOB_D would use always use S1.

Defining Notifications
Use Notifications to create output files based on task statuses and send those output files to email addresses or
any Output Device defined in Applications Manager. To use Notifications, you:
 Applications Manager 9.4.1

• Define a list of one or more Notification details.

• Assign the Notification to Applications, Program Types, Jobs, and Process Flow components.
You define Notification objects, and then assign them to Process Flow components, Jobs, Applications, and
Program Types. A sample Notification definition is shown below. If a task has Notifications defined for it in multiple
objects, all Notifications are performed.
Prerequisite: Specifying Email Settings
In order to send Notification emails, you must specify email settings for the Applications Manager Automation
Engine/Local Agent.
Creating Notifications
To add Notifications using the Applications Manager client:
1. From the Notifications Selector window, click New.
Applications Manager opens the Notifications window.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a name and description for the object.
3. After creating the Notifications object, add Notification details.
Adding Notification Details
To add Notification details to a Notifications object:
1. From the Notifications window, click the New button.
Applications Manager opens the Notification Details window.
2. Complete the fields in the Notification Details window using the information below.
3. To save the settings and add the Notification detail, click OK.
Applications Manager adds the Notification detail to the Details table on the Notifications window.
Notification details are evaluated in the order they are listed. If you wish to reorder them, use the arrow buttons
to the right of the list.
Assigning Notifications
After you have defined a Notification object, you can assign it to Process Flow components, Jobs, Applications,
and Program Types. If you assign the object to an Application, the Notification will apply to any Job assigned to
that Application. The same holds true if you assign the object to a Program Type. Being able to assign Notification
objects to Applications and Program Types makes it easy to set up Notifications for a whole class of Jobs.
Notification Field Description
• Frequency
Applications Manager evaluates Notifications for a task at least every 59 seconds. However, you select how
often the action for each Notification detail should be taken:
• First Time: Applications Manager only initiates the specified action the first time the Notification detail is true.
• Every Time: Applications Manager initiates the specified action every time the Notification detail is true.
• Status Trigger
Specifies the status that will trigger the Notification:
• Finished: The task goes to a FINISHED status.
• Deleted: The task is deleted from the Backlog.
• Aborted: Any failure status, such as ABORTED or TIMED OUT.
• Failed to Start: Any status that prohibited the task from running, such as LAUNCH_ERROR, DIED, or
DB_ERROR.
• Hold: The task is put into a HOLD status.
• Running: The task goes into a RUNNING status.
• Completed: The task completes without regard to status.
• Queued: The task goes to QUEUED status.
• Requested: The task is requested or run with awrun.
• Restart Finished: A task was restarted and has finished with a decimal value run ID rather than an integer.
 Applications Manager 9.4.1

• Condition: Indicates that this Notification is one that is meant to be used in a SEND NOTIFICATION condition
action. For an example, see Checking and Notifying the Time Since Request.
• Message Text
Specifies the message sent to the email recipients and Applications Manager Output Devices you select. The
message text is also written to an output file named notif_<run_id>_<series> that you can view on the Output
Files tab of the Task Details window from the Backlog and History.
• Template: Uses a Message Template object to specify text. For more information, see Defining Message
Templates.
• Custom Text: Text to be used for this Notification only.
Either method allows the use of Substitution Variables and Replacement Values for variable text.
• Subject
Text written as the subject when sent as an email. Allows the use of Substitution Variables and Replacement
Values. The default subject, {status} {run_id} uses Replacement Values to alert the recipient(s) of the status
and run ID of the task.
• Email Recipients
List of one or more email addresses to receive email Notification. Separate multiple email addresses with a
space or semicolon. To select from emails assigned to Users, click the Select button. Applications Manager
opens a window where you can select the email addresses.
In order to send Notification emails, you must specify email settings for the Applications Manager Automation
Engine/Local Agent.
• Email Attachments (radio buttons)
Specifies the output files to attach to the emails specified above and the Output Device specified below (if
allowed in its definition):
• System Output: Attaches only the system output file.
• Other Output: Attaches all registered output files, except the system output file.
• All Output: Attaches all registered output files including the system output file.
• Pattern: Attaches files of a particular name. For wildcard pattern matching, use the % character or .*. For
example, enter report% to specify all output file names beginning with report. To attach two files, create two
Notification details.
• Normal
When selected, file contents are attached to the email.
• In Body
When selected, file contents are included in the email body rather than as attachments.
• Zip
When selected, files are attached in a zip file.
• Pdf
When selected, files are converted to a PDF file and attached.
• PDF Options: You can choose the PDF format to be generated. You can select Portrait or Landscape.
• Size Limit: You can provide the PDF size limit in KBs. For example, if you specify 2KB, the attachment will
contain a PDF of up to 2KB only. If the generated file exceeds the size limit, the PDF is not attached and
you will receive an email notification for the same. If you specify zero or if it is left empty, the file size can be
unlimited.
• System Output As
Renames the attached system output file to whatever name you select. To use the file name for the system file,
use the {file_name} Replacement Value. For example, {file_name}.txt.
• Other Output As
Renames the attached output file(s) to whatever name you select. To number multiple other output files, use the
special Subvar {#}. For example, assume you want to rename output for a program to finance{run_id}, and the
task creates two or more output files. You might enter finance{run_id}{#} in this field.
To use the file name for the other file(s), use the {file_name} Replacement Value. For example, {file_name}.txt.
• Output Device (On Output Device tab)
 Applications Manager 9.4.1

Specifies the Output Device or set of devices where the output will be sent (for example: EMAIL, ACCOUNTING
LASER, ATLANTA LASER). Printing to Output Devices for Notifications will be done on the Automation Engine
machine rather than on Remote Agents.
• Output Option (OnOutput Devicetab)
Used for specifying dynamic output options for the selected Output Device. This field will be active if this value
or list of values is defined by the Output Interface assigned to the Output Device.
Deleting Notification Output Files
When you define a Job, you can set the number of days the output will be retained by Applications Manager in the
Retention days setting on each Job's Output tab. When a Notification is assigned to the Job, it will use that Job's
retention days to determine when to delete the Notification's log files.
The SODELETE Job (alias DELDEFAULT) deletes the output files that have exceeded their retention settings.

Defining Message Templates

Use Message Templates to specify text to include in Notification output files. An advantage of Message Templates
is that you can include Subvars and Replacement Values such as #today and {run_id}.

Applications Manager User Groups control access to Message Templates. If you do not have access to them, see
your Applications Manager administrator.
Procedure
To define a new Message Template:
1. From the Message Templates Selector window, click New.
Applications Manager opens the Message Templates window.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a name and description for the Message Template.
3. Enter the message to include in your Notifications. To include Substitution Variables or Replacement Values in
the text search, click the { } button.
What Users See
 Applications Manager 9.4.1

The Message Template shown below is assigned to a Notification. That Notification is assigned to a Job. When that
Job aborts, the text from the Message Template is written to an output file named notif_<run_id>_<series>. Note
that the values for the Substitution Variables and Replacement Values are displayed in the output file.

Defining Environment Variables

There are many cases where you may want to set one or more Environment Variables before a task runs. In
Applications Manager, you can define Environment Variables and assign them to Agents, Applications, Program
Types, and Jobs. In the image below, the Oracle SID is set with a Environment Variable.
 Applications Manager 9.4.1

You can define and store values for one or more Environment Variables as a single Applications Manager object.
To use Environment Variables, you:
• Define a list of Environment Variables.
• Assign the Environment Variables to Agents, Applications, Program Types, Jobs, and Process Flow
components.
Creating Environment Variables
To add Environment Variables to the Applications Manager client:
1. From the Environment Variables Selector window, click New.
Applications Manager opens the Environment Variables window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a name and description for the object.
3. After creating the Environment Variables object, you will add variables to it.
Adding Variables
To add variables to an Environment Variables object:
1. From the Environment Variables window, click the New button.
Applications Manager opens the Environment Variable window show above.
2. Complete the fields in the Environment Variable window using the information below.
• Name
The name of the Environment Variable. Names cannot start with numbers. To include Substitution Variables
or Replacement Values in the name, click the { } button.
• Value
The value of the Environment Variable. To include Substitution Variables or Replacement Values in the text,
click the { } button.
• OS
Specify the applicable operating system(s) you want to include this variable for.
3. To save the settings and add the variable, click OK.
Applications Manager adds the variable to the Variable table on the Environment Variables window.
Environment Variables are evaluated in the order they are listed. If you wish to reorder them, use the arrow
buttons to the right of the list.
Using Environment Variables in Prompts
You can include Environment Variables in prompt values. The Environment Variables must be enclosed in { } curly
brackets. When an Environment Variable is used in a prompt's value, its corresponding Environment Variable
object must be assigned to the Job via its Agent, Application, Program Type, or Job definition.
Order of Precedence for Environment Variables
These variables will be written to the .pm file after all other variables are set by the operating system, User, script,
etc. Be careful not to overwrite any variables unintentionally. Environment Variables can be assigned in five
places in the Applications Manager user interface: Agents, Applications, Program Types, Jobs and Process Flow
components. When a task runs, Applications Manager looks at each task's Agent, Application, Program Type, Job,
and Process Flow assignments—in that order. Each object can override any individual variables that are previously
set. For example, if variable X is defined as = '1' for an Agent and also defined for the Application as = '2' then the
program will see X=2 since Application follows Agent.

Storing and Calculating Job Average Run Times

The Ave run time field provides a location to store the average run time for a Job. You can update the average run
time by:
• Manually entering a value in this field.
• Calculating the value by clicking the Calculate button.
 Applications Manager 9.4.1

• Running the AW_CALC_AVE_RUN_TIMES_1 Job to populate it for all Jobs and Process Flow components. For
more information, see Running the CALC_AVE_RUN Job.
The value from this field will be displayed in the Gantt charts on the Backlog Gantt View, History Gantt View,
Graphical Forecast, and Process Flow Gantt View windows.
Using the Calculate Button
To calculate average run times based on History, click the Calculate button. Clicking the Calculate button opens
the window where you enter start and end times shown below. You can use the Calendar icons to select these
times from a Calendar window. Once you select dates and click OK, the window closes and Applications Manager
opens the window shown below.
 Applications Manager 9.4.1

On that window select some or all of the historical listings for the Process Flow from the table, click Calculate, then
click OK.

Running the CALC_AVE_RUN Job

The CALC_AVE_RUN Job serves two purposes for Jobs in one or more applications. It:
• Creates a report of average, last, or maximum task runs.
• Optionally populates the Ave run time field for Jobs and Process Flow components.
The CALC_AVE_RUN_TIMES Job includes the following prompts:
• Applications
A multi-select prompt where you select which applications' task run times you wish to calculate.
• Ave Run Time Calc Method
A list of values prompt with three options:
• AVG: Average value
• LAST: Last value
• MAX: Maximum value
• Maximum number of days of history
The number of days you wish to use in the calculation.
• Minimum number of runs
The number of runs you wish to use in the calculation.
• Commit new Ave run times
Y or N to determine whether you wish to populate the Average Run Time field for the Job with the value from
this report.
Sample CALC_AVE_RUN Output
 Applications Manager 9.4.1

In the example below, the CALC_AVE_RUN Job was run for an application named AVE. Its prompt values are
listed at the top of the output file. Below that its details are given when it is run as a Process Flow component, or a
stand-alone Job.

Applications included
AVE
Type =AVG
Days =60
Min Runs =1
Commit =Y
-----------------------------
-----------------------------
Chain (*) Average Runtime Method=AVG
-----------------------------
Chain Name/..Component Name Jobs Min Max Average ddd:hh:mm:ss
*TEST_AVE_PROCESS_FLOW 2 127 306 217 000:00:03:37
..TEST_AVE_01 2 122 301 212 000:00:03:32
..TEST_AVE_02 2 122 301 212 000:00:03:32
..TEST_AVE_03 2 122 301 212 000:00:03:32
-----------------------------
-----------------------------
Job Average Runtime Method=AVG
-----------------------------
Job Name Jobs Min Max Average ddd:hh:mm:ss
TEST_AVE 5 61 301 175 000:00:02:55
TEST_AVE_01 2 122 301 212 000:00:03:32
TEST_AVE_02 2 122 301 212 000:00:03:32
TEST_AVE_03 2 122 301 212 000:00:03:32

Specifying Output Options for Jobs

Using the Output tab shown below, you can control what happens to the output of Jobs. The values of the Output
Group, Output Device, Output Option, and Copies fields are only used if PRINT is selected as the Output
Function.
 Applications Manager 9.4.1

Job Output tab fields are described below.

• Output Group
The generic type of device that the task will be sent to (for example: LASER_PRINTER, FAX,
[email protected], TRAINING_DEPARTMENT, or BELLEVUE). The Output Group you select
determines the devices displayed in the Output Device list box
• Output Device
Specifies the default Output Device or set of devices where the output will be sent (for example: EMAIL,
ACCOUNTING LASER, ATLANTA LASER). You must select an Output Group before you can select an Output
Device.
Output settings in the Job definition can be overridden by component settings when the Job is added to a
Process Flow.
• Output Option
Specifies options for the selected Output Device. If the Output Device does not use output options, this field will
be inactive.
• Output function
Determines how output is handled. With any of these settings, the application output or report files and the
system output files are viewable from the Explorer window. There are three choices:
• LOG: Legacy setting. Should not be used unless you need to use the Output window rather than the
Explorer window. Applications Manager loads all application output or report files for viewing in the Output
window for tasks with a LOG output function every time a User logs into the client. This can take several
seconds or minutes. If more than 500 files are loaded, an alert will be displayed. Therefore, if users are not
using the Output window (that is, they view output from History instead of the Output window, or output is
emailed to them), you should use the STORE setting.
• PRINT: The output is printed.
 Applications Manager 9.4.1

• STORE: The output is not printed.

The setting specified here can be overridden when the Job is added to a Process Flow or requested on an ad
hoc basis.
• Copies
Specifies the number of copies to print if a printer is selected as the Output Device (1-99).
• Retention days
Sets the number of days the report output and system output generated by the program will be stored on the
system before it is deleted. The range is from 0 to 999 days. If set to zero, the current day is not counted, and
the output of the Job will be deleted the next day.
Changing this setting will only affect future runs of this Job. It will not affect the output of tasks that ran before
the change was made.
You can override the retention days for all components in a Process Flow. For more information, see Overriding
Job Retention Days Setting at the Process Flow Level.
• Max # of revisions
Determines how many past versions of a Job's output will be stored on the system. This setting applies to the
Job when it is run by itself or included in Process Flows. When you select Max # of revisions, Applications
Manager finds the oldest revisions and deletes them so that only the maximum number of output entries
(revisions) is left.
If a program generates multiple reports as separate files, each file counts against this setting. For example, if a
program produces two report files, and you want to retain the last three versions of each of them, you would set
Max # of revisions to 6 (2 output files x 3 revisions = 6). You would then retain six total reports as well as six
system output files.
Applications Manager treats system output as one group, deleting all output assigned to the SYSOUT Output
Device for a particular Job up to the maximum number of revisions. Then it deletes all outputs up to the
maximum number of revisions for all the other Output Devices.
This option is not active unless the Use job max revisions option is turned on for the Automation Engine/Local
Agent. For more information on Automation Engine options, see the Administration Guide.
• Program options
Passes standard command line options to the program called by the Job. The options should be those that
could not be defined in the Program Type. The value of this field is stored in the operating system environment
variable rpf_options.
• Output directory
Applications Manager normally sends output to the directory specified for the Agent. Leave this field blank
unless the program requires the output files for the Job to be sent to a different directory. This field may be up
to 32 characters long. If you enter a directory here, be sure it exists and that Applications Manager has read/
write permissions to it. You can use Substitution Variables in this field. This setting is overridden if a directory is
entered in the Output Directory field on the Users window. For more information, see the Administration Guide.
• Print system output logs
When selected, the system output from the Job is tagged for printing. By running the script $AW_HOME/sql/
sysout.sql, you can print the system outputs of all Jobs that have been checked. To print these system outputs,
create a Job to run sysout.sql.
The Job that runs the sysout.sql script must have an Output Device assigned to it for the output to be printed.
• Abort if no output
When selected, Applications Manager will abort the Job if no output is generated. Use this option for Jobs
whose key function is to produce a printed report.

Adding Job Documentation

You can enter customizable general and abort documentation for Jobs, Process Flows, and Process Flow
components. By selecting an individual task and choosing Documentation, operators can access these comments,
suggestions, or instructions.
Documentation provides a location to enter relevant information about the processing of tasks. Documentation for a
sample LOADER Job is shown below.
 Applications Manager 9.4.1

Types of Documentation
There are two types of customizable documentation: general and abort. General documentation usually contains
information on goals and requirements or existing security and access issues. Abort documentation usually
contains information on what action to take if a Job aborts or fails, who to contact if a Job aborts, or what
considerations exist when running a task.
Documentation Locations
There are three locations within Applications Manager where you can enter documentation. Suggested uses for
documentation are described below:

Location Description

Job Useful when the Job is going to be requested ad hoc, or

when the documentation for the Job would be useful—
regardless of how the Job was invoked.

Process Flow Can be used to provide information which is relevant to

the entire Process Flow.
 Applications Manager 9.4.1

Location Description

Process Flow component Can be used to provide specific information about one
component in a Process Flow.

Documentation Format
You can enter documentation in plain text or in HTML format. If you enter HTML code and select the HTML
checkbox the note will be displayed in HTML format.
Including Hyperlinks and Images in HTML Documentation
You can add hyperlinks and images in HTML documentation. The links will work when the client is launched via
Java Web Start. They will not work when you launch the client from the command line with the appworxj command
(or in Motif startso client). You create links using standard HTML tags.
An example HTML hyperlink is shown below:

<P>Please visit the <a href="https://www.broadcom.com/">Broadcom Corporate Web Site</a>.

An example linked graphic tag is shown below:

<P><img src="http://casupport.broadcom.com/images/index/indexlogo_small.gif" border="0">

You can link to images from the Applications Manager Automation Engine directory structure using the {codebase}
environment variable. In the example below, an image named splash.png includes a hyperlink to the Broadcom
Support site. The location of the image is the images directory under the directory specified by the {codebase}
environment variable.

<center><a href="http://casupport.broadcom.com"><img height="126" width="602" alt="Broadcom

Support" src="{codebase}../images/splash.png" border="1"></a></p></center>

You cannot have a slash after {codebase}. Notice in the example above that two dots follow the {codebase}
environment variable to go back one directory.
The default documentation for TEST_JOB includes example test and graphic links.
Procedure
To add documentation to a Job, Process Flow, or Process Flow component:
1. From the Documentation tab of the Job, Process Flow, or Process Flow component, select an option from the
Documentation type drop-down box
2. Type in comments, tips, suggestions, and precautions.
When entering documentation remember:
• Lines do not wrap. To start a new line, press Enter.
• You can cut and paste text.
3. If you wish, you can select the other tabs on the Jobs window to edit them at this time.
4. Click Apply to add the Job definition to the list of Jobs, or OK to add the new definition to the list of Jobs and
close the Jobs window.
Adding New Documentation Types
By default there are General and Abort documentation types for Jobs, Process Flow, and Process Flow
components. You may want to add an additional type. To do this log into the Applications Manager Oracle database
 Applications Manager 9.4.1

and issue SQL such as the following. In this example, M specifies Jobs for the note type, and Change History is the
new note category.

SQL> insert into so_doc_types select 'M', 'Change History' from dual;

To create note types for Process Flows or Process Flow components you need to change the above M value
accordingly:
• M - Job
• C - Process Flow
• D - Process Flow component
Viewing Task Documentation
Users can view Job, Process Flow, and Process Flow component documentation from the Backlog, History, Submit
window, and Backlog Gantt View window. If a task aborts, an operator can view the specific abort documentation
and make more effective operational decisions.

Assigning User Groups to Jobs

User Groups are used in Applications Manager to control access to objects. User Groups can be added to a Job
from the User Groups tab as well as from the User Group itself.
If you cannot assign a User Group to an object when you have both the User Group and the object in one or more
of your roles, it may be because you have the User Group assigned to your User, but not to any of your User
Groups. Your Applications Manager administrator can remedy this by assigning the User Group to itself.
 Applications Manager 9.4.1

If you are assigned to a maintenance User Group, all Jobs you create will automatically be assigned to your User
Group when you define them. You can view a list of objects that you have access to by going to the View menu
and selecting View Assigned Objects. If you do not have access to an object, see your Applications Manager
administrator.
Procedure
To assign User Groups to a Job:
1. From the User Groups tab, assign and unassign User Groups by double-clicking on the User Group names.
You can also highlight a User Group and select the arrow buttons to assign and unassign it. Use the double
arrow buttons to assign or unassign all User Groups to the Job.
2. Select a Job/Process Flow option for each User Group in the Usage column. The Job/Process Flow options are
described below:

Option Description

Both Users can submit these Jobs and view the output with
the file viewer.

Output only Users can view the output of these Jobs, but not
request them.

Request only Users can submit these Jobs, but not view their
output.
 Applications Manager 9.4.1

3. If you wish, you can select the other tabs on the Jobs window to edit them at this time.
4. Click Apply to add the Job definition to the list of Jobs, or OK to add the new definition to the list of Jobs and
close the Jobs window.
For more information on User Groups, see the Administration Guide.

Troubleshooting Newly Created Jobs

When creating Jobs, you will need to test them to make sure they run correctly. Sometimes they finish successfully,
and sometimes they abort. There are several reasons why Jobs abort. The reasons why a newly created Job
aborts are often different than why an existing Job aborts. This topic discusses the most common reasons why
newly created Jobs abort. A newly created Job may abort when:
• The program or script run by the Job fails.
• Program information is not correctly defined.
• A Login to a database, application, or host is not correctly defined.
• Prompt values are not being sent correctly.
Each of these is discussed below.
When troubleshooting aborted tasks, you need to know how to take actions on tasks in the Backlog and view/edit
task details as described in the User Guide. It may also be necessary to turn on debug and re-run your tasks as
described in the Administration Guide.
Running the Program or Script Independent of Applications Manager
Some newly created Jobs abort because the program or script they run fails. If a Job aborts, it is always a good
idea to try and run the program or script from the command line to verify whether the problem is in the program or
Applications Manager.
Troubleshooting Program Information
A Job will abort if information has not been entered correctly in the Agent/Group field, and the Library, Type (for
Program Type), and Program name fields in the Program box on the General tab. The General tab for a sample
Job is shown below.
If a single Agent is selected from the Agent/Group field, the program or script run by the Job must exist on the
machine specified in the Agent's definition. Additionally, you will be able to use the Select button to search for the
program or script once the correct Library and Program Type are selected. You can type in a program or script
name in the Program name field, but if you do, Applications Manager will not verify that it exists on the Agent.
If an Agent Group is selected, the program or script must exist on all the Agents in the group. When an Agent
Group is selected for a Job the Select button will be grayed out, and the Location field will be empty.
 Applications Manager 9.4.1

A Job may abort if the program or script it is supposed to run does not exist, or is defined incorrectly. Sample output
from a Job's system output file when a file name is incorrect is shown below:

file /home/tech6/sql/employee.sql does not exist

Error messages may differ depending on your operating system.

For more information on defining program information, see Entering General Information for Jobs.
Troubleshooting Logins
If a Job will be running a program that requires a login to a database, application, or host, you must assign a Login
(or in some cases two Logins) to the Job on the Job's Execution Options tab as shown below.
 Applications Manager 9.4.1

A Job requiring a Login will abort if the correct Login is not selected. Sample output from a Job's system output file
when the wrong Login was set is shown below:

ORA-01017: invalid username/password; logon denied

Error messages may differ depending on your operating system.

If your login is denied, you should be able solve the problem by examining the following. You may need to work with
your Applications Manager administrator or DBA to find some of this information:
• Is a Login assigned to the Job?
• Are you sure which Login the Job is using? Depending on the setting on the Job's Login source options, you
may be using the Login assigned to your User. The Job will use a Login defined for your User if the User's
Login radio button is selected, or if the Default radio button is selected, and User's Login is selected as the
Login type for the Automation Engine/Local Agent.
• Is the name and password associated with the Login valid? If the name and password for the Login are valid,
you should be able to log into the database, Happlication, or host outside of Applications Manager.
 Applications Manager 9.4.1

Troubleshooting Prompts
If the program called by a Job requires arguments, you use prompts to request data that will be passed to variables
in the program. Jobs abort, run incorrectly, or finish without generating output when bad prompt values are passed
to a program or script. Sample output from a Job's system output file when a character was passed when a
numeric argument was required is shown below:

expr: non-numeric argument

starting at Wed Jan 19 10:18:10 PST 2005
sleep: invalid time interval `x'

Selecting the correct data type will prevent prompt values of the wrong format from being entered.

Updating Job/Process Flow Characteristics with BULK_CHANGES

The BULK_CHANGES Job allows you to make bulk changes to a characteristic of Jobs and Process Flows without
having to edit a huge number of objects, or write custom SQL statements.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Characteristics you can change include:

• Applications
• Agents/Agent Groups
• Queues
• Output functions
• Output Devices
• Notifications
• Output Scans
• Environment Variables
Example Uses
You might want to run a bulk change if:
• You want to change an Application name by creating a new one, reassigning Jobs and Process Flows to it, and
deleting the old Application.
• You have two objects defined for the same purpose, and you want to reassign Job and Process Flows to one
and delete the other. Sometimes two people create objects for the same purpose. For example, two developers
might create Notifications with nearly the same definition when only one is necessary.
• Too many Queues are defined. Sometimes people define too many Queues unnecessarily. Defining multiple
Queues with the same settings doesn't serve any beneficial purpose and can slow down the time it takes for the
Automation Engine to scan them.
• The LOG output function is assigned as some Jobs, but the Output window isn't being used, so you want to
change the output function of those Jobs to STORE. When LOG is set, report files will be listed by default in
the Output window. Applications Manager loads all application output or report files for viewing in the Output
window for tasks with a LOG output function every time you log into the client. This can take several seconds
or minutes. If more than 500 files are loaded, an alert will be displayed. Therefore, if no users view output from
the Output window (that is, they view output from History instead of the Output window, or output is emailed to
them), you should use the STORE setting.
Prerequisite
Before requesting the BULK_CHANGES Job, you must first import it into Applications Manager. The
BULK_CHANGES Job is found in the aw_bulk_changes import file. For information on running Applications
Manager imports, see chapter Exporting and Importing Objects.
Procedure
To run the change Job/Process Flow characteristic with the BULK_CHANGES Job:
1. Request the BULK_CHANGES Job.
2. Use the Select buttons to pick the characteristics from any of the first eight prompts that you wish to "change
from" for one or more Jobs and/or Process Flows.
3. Use the Select button in the 'Jobs to be changed' prompt to pick the Jobs and Process Flows you want to
change.
4. Use the Select buttons to pick the characteristics from any of the final eight prompts that you wish to "change
to" for one or more Jobs and/or Process Flows.
5. Submit the BULK_CHANGES Job.
When the BULK_CHANGES finishes, the Job/Process Flow definitions will be updated.

What Are Process Flow Requestor Jobs?

Process Flow requestor Jobs provide an alternative method of running a Process Flow. If you are new to
Applications Manager, you will probably never use them. They only exist today for legacy customers and you
cannot define new ones.
Process Flow requestor Jobs provide an alternative method of running a Process Flow. In prior versions of
Applications Manager, you could not:
• Add Process Flows directly to other Process Flows.
• Submit Process Flows on an ad hoc basis.
You had to create schedule Jobs to do these things. A sample Process Flow requestor Job is shown below.
 Applications Manager 9.4.1

In the current version of Applications Manager, you can add Process Flows to other Process Flows and request
Process Flows from the Requests window. You can also add prompts to a Process Flow. When you run a Process
Flow that includes prompts, the values from these prompts can be passed to the components in the Process Flow
using numeric Substitution Variables. With these improvements, it is no longer necessary to create a Process Flow
requestor Job for your Process Flows. If you are new to Applications Manager, you will probably never use Process
Flow requestor Jobs. They only exist in Applications Manager today for 4.x and 5.0x customers and you cannot
create new ones.
Process Flow Requestor Jobs in the Backlog
Process Flow requestor Jobs behave exactly like Process Flows in the Backlog. When you request a Process Flow
requestor Job, it goes into an INITIATED status once the Process Flow components are inserted into a Queue. Like
a Process Flow, you can right-click the Process Flow requestor Job to change its status, which in turn will affect the
status of all eligible components.
 Applications Manager 9.4.1

Creating Process Flows

Process Flows are used to schedule and execute one or more Jobs and other Process Flows. Process Flows
transfer the chore of routine maintenance and scheduling from operations personnel to Applications Manager.
In many operations environments, shell scripts are used to run programs. A shell script may run a series of
programs in a specific order, on certain days, and under certain conditions. In Applications Manager, Process
Flows take the place of shell scripts. A Process Flow includes one or more Process Flow components (Jobs and
Process Flows assigned to the Process Flow), general scheduling information for the Process Flow, specific
scheduling information for each Process Flow component, and conditions that must be met for each component
to run. Since a component can be either a Job or Process Flow, Applications Manager gives you a great deal of
flexibility in building Process Flows. The Process Flows window is shown below.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Process Flows. If you do not have access to them, see your
Applications Manager administrator.
Running Process Flows
There are two ways to run a Process Flow:
• Enter scheduling information using the Schedule tab on the Process Flows window.
• Request and submit one or more Process Flows/Jobs by opening the Activities menu and selecting Requests.
• Request and submit a single Process Flow using the Request button in the Process Flow definition.
999 Components and 32 Levels in a Process Flow
A Process Flow may contain up to 999 components. A Process Flow can include a Process Flow, which in turn
includes another Process Flow. Process Flows nested within other Process Flows are called sub Process Flows.
You can have up to 32 levels of sub Process Flows. As a rough guide, four levels of sub Process Flows is sufficient
for most implementations.
Components in a Process Flow Point to Original
Process Flow components are Jobs and Process Flows assigned to the Process Flow. When you add a component
to a Process Flow, Applications Manager creates a pointer from the Process Flow to the Job or Process Flow
instead of adding a copy of it. This is in keeping with the Applications Manager object-oriented approach. If you edit
a Job or Process Flow definition, the update is effective immediately for all Process Flows that include it.
Basic Steps for Creating a Process Flow
To create a Process Flow you:
1. Add the Process Flow object (also called the Process Flow header).
2. Add components to the Process Flow.
3. Specify options for the components.
4. Schedule the Process Flow (if desired).
Steps one and two are described in this chapter, step three is described in chapter Editing Process Flow
Component Information, and step four is described in chapter Scheduling Jobs and Process Flows.
Adding Documentation to Process Flows and Process Flow Components
Documentation provides a place to enter relevant information about the processing of a task. By selecting an
individual task and choosing Documentation, operators can access these comments, suggestions, or instructions
for the individual task. There are two types of documentation: abort and general. Documentation can be formatted
in plain text or HTML.
 Applications Manager 9.4.1

You can enter customizable general and abort documentation for Jobs, Process Flows, and Process Flow
components. For more information, see Adding Job Documentation.

Defining Process Flows

The minimum requirement for creating a Process Flow is filling in the required fields on the General tab. However,
the Process Flow cannot do any 'work' until you add components to it.

You can define certain objects by clicking the icon to the right of their field. Applications Manager will display the
selector window where you can define the new object. For example, you can click the Application icon to display
the Application Selector window. Fields marked with an '*' on their right are required.
Jobs and Process Flows should not be edited while running the STAGING Job or executing exports and imports.
Procedure
To add an Applications Manager Process Flow:
1. From the Process Flows Selector window, click New.
Applications Manager opens the Process Flows window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a name and description for the Process Flow on the General tab of the Process Flows window.
The name may be up to 30 characters long and the description may be up to 99 characters long. Process Flow
names can include letters, numbers, periods, colons, underscores, and hyphens. The first letter of a Process
Flow name must be a letter or number.
3. Select an Application.
Applications are the general category to which Jobs and Process Flows belong (such as inventory or accounts
payable). They are used on the Requests window to limit the list of Jobs and Process Flows. For information on
Applications, see Defining Applications.
4. If appropriate, select an Agent from the Default agent field. You can use this field to:
 Applications Manager 9.4.1

• Select the default Agent for the Process Flow: The default Agent is only used for Process Flow
components whose Jobs are assigned to Agent Groups. For the Process Flow component to execute on the
default Agent, two conditions must be met:
• The default Agent must belong to the Agent Group assigned to the Job.
• The Agent field in the Execution group box on the General tab for the component must be set to 'No
Selection'.
• Assign the Process Flow to a multi-execution Agent Group: When a multi-execution Agent is assigned
to a Process Flow, the Process Flow and its component will run on every Agent in the Agent Group definition.
A Process Flow's Agent setting can be overridden on the Process Flow's Schedule tab or on the Submit
window when requesting the Process Flow on an ad hoc basis.
For more information on Agent assignments for Process Flow components, see How Agent Assignments Are
Handled for Process Flow Components.
5. Assign values to the fields in the Execution options box.
These fields are described in Entering Execution Options for Process Flows.
6. If you wish, you can edit the information on the other tabs in the Process Flows window at this time.
7. To add the Process Flow definition to the list of Process Flows, click Apply. Or to add the new definition to the
list of Process Flows and close the Process Flows window, click OK.
Applications Manager displays an error message to alert you to any required fields that have not been filled in.

Using the Tabs of the Process Flows Window

The Process Flows window includes several tabs as shown below. Some of the tabs are more commonly used
than others. Additionally, the Process Flows window includes several of the same tabs as the Jobs window. For
these reasons, some tabs on the Process Flows window are described in this chapter and others are described in
other chapters.

Process Flows Tabs Discussed in this Chapter

The following tabs are discussed in this chapter:
General: Specifies the name and description of the Process Flow. It tells also Applications Manager how to run
the Process Flow. Many of the fields on this tab are required. For details, see topics Defining Process Flows and
Entering Execution Options for Process Flows.
Output: Controls the output options for Process Flow components that have the Use Request Output Device option
set. For details, see Specifying Output Options for Process Flows.
Components:Specifies components in the Process Flow. After you create a Process Flow, the next step is to add
components to it. It is the components in a Process Flow that accomplish work. Components can include both
Jobs and Process Flows. For details, see Working with Process Flows. After creating a Process Flow, you can
specify how each component will run. You select its eligible run days and execution options, and define special run
conditions. For details, see chapter Editing Process Flow Component Information.
Process Flow Tabs Discussed in Other Chapters
The following tabs are discussed in other chapters:
Schedule: Creates schedules to run the Process Flow. Schedules can be based on days of the week, specific days
of the month, and days in a Calendar. You can create more than one schedule for a Process Flow. For details, see
chapter Scheduling Jobs and Process Flows.
Prompts: Passes values to components. If prompts are defined for one or more components in the Process Flow,
you can pass values to them from the Process Flow. For more information, see Passing Values Through a Process
Flow with Numeric Subvars.
 Applications Manager 9.4.1

Conditions: Controls the execution of tasks. Conditions provide IF/THEN logic for your Process Flow. They can be
evaluated before, during, and after a task executes, or after a task is deleted. For details, see chapter Working with
Conditions.
Documentation: Provides a location to enter relevant information about the processing of a task. By selecting an
individual task and choosing Documentation, operators can access the comments, suggestions, or instructions with
respect to an individual task. For details, see Adding Job Documentation.
User Groups: Controls access to Process Flow. User Groups can be added to a Process Flow from the User
Groups tab well as from the User Group itself. User Groups are usually defined by your Applications Manager
administrator. For details, see Assigning User Groups to Jobs.

Entering Execution Options for Process Flows

You can set a variety of options that determine what happens to a Process Flow and its components when the
Process Flow executes in the Execution options box shown below, found on the General tab of the Process
Flows window.

The Execution options fields are described below:

• Queue
Specifies the default Applications Manager Queue the Process Flow will be submitted to. Components of this
Process Flow will run on their own Queue rather than the Queue selected here.
If you want all Process Flow components to run on the Process Flow's Queue, you must select the Insert
components into process flow's queue option for the Automation Engine/Local Agent. For more information,
see the Administration Guide.
If the Process Flow is run using a schedule and that schedule includes a Queue, that setting overrides the
Process Flow's Queue. If the Process Flow is submitted on an ad hoc basis, the User may have the option to
change the Queue on the Submit window.
• Priority
 Applications Manager 9.4.1

Determines the priority for when this Process Flow gets initiated. This setting usually isn't crucial. Process Flows
are initiated as soon as they are inserted into the Backlog and their components' priorities are based on their
Job definitions.
A Process Flow's priority specifies when this Process Flow gets initiated in relation to:
• When other Process Flows submitted to this Queue at the exact same time get initiated.
• When stand-alone Jobs waiting in this Process Flow's Queue run.
The order that Process Flows initiate does not affect the order in which their components run. It does affect the
order in which their BEFORE conditions are evaluated (if they have any).
The top priority setting is 1, and the bottom is 99. The default is 50.
Process Flows submitted with 0 priority will have the status of NO PRIORITY in the Backlog and their
components will not run.
• Ave run time
This non-editable field specifies the average run time of the Process Flow (DDD:HH:MI). This time is displayed
in the Gantt charts on the Backlog Gantt View, History Gantt View, Graphical Forecast, and Process Flow
Gantt View windows. To recalculate the average run time, click the Calculate button.
• Single run
When selected, two instances of the Process Flow cannot run concurrently. The second instance of the Process
Flow will wait in a SELF_WAIT task status until the first completes.
• Active
When selected, the Process Flow will run when scheduled or included in another Process Flow and be available
from the Request window. If not selected, the Process Flow will not run when scheduled or included in another
Process Flow, and it cannot be run from the Requests window.
Overriding a Process Flow Component's Queue
If you wish to override the Queue for an individual component in a Process Flow, add a condition like the one
shown after below to the component. For more information on creating conditions, see chapter Working with
Conditions.
 Applications Manager 9.4.1

Specifying Output Options for Process Flows

Using the Output tab shown below, you can control the output options for Process Flow components that have
the Use Request Output Device option set. For more information on the Use Request Output Device option, see
Specifying Output Devices. These settings can be overridden from the Submit window when requesting the
Process Flow on an ad hoc basis. This might be useful if you are submitting a Job or Process Flow and you want to
print the output to your local printer. Developers might use this feature to check output when testing a program.
 Applications Manager 9.4.1

Process Flow Output tab fields are described below.

• Output Group
The generic type of device that the task will be sent to (for example: LASER_PRINTER, FAX,
TRAINING_DEPARTMENT, or BELLEVUE). The Output Group you select determines the devices displayed in
the Output Device list box
• Output Device
Specifies the default Output Device or set of devices where the output will be sent to (for example: EMAIL,
ACCOUNTING LASER, ATLANTA LASER). You must select an Output Group before you can select an Output
Device.
• Output Option
Specifies options for the selected Output Device. If the Output Device does not use output options, this field will
be inactive.
• Output Function
Determines how output is handled. With any of these settings, the application output or report files and the
system output files are viewable from the Explorer window. There are three choices:
• LOG: Legacy setting. Should not be used unless you need to use the Output window rather than the
Explorer window. Applications Manager loads all application output or report files for viewing in the Output
window for tasks with a LOG output function every time a user logs into the client. This can take several
seconds or minutes. If more than 500 files are loaded, an alert will be displayed. Therefore, if users are not
using the Output window (that is, they view output from History instead of the Output window, or output is
emailed to them), you should use the STORE setting.
• PRINT: The output is printed.
• STORE: The output is not printed.
The setting specified here can be overridden when the Process Flow is requested on an ad hoc basis.
• Default Copies
Specifies the number of copies to print if a printer is selected as the Output Device (1-99).

Overriding Job Retention Days Setting at the Process Flow Level

Retention days dictate the number of days the report output and system output generated by a Job's program are
stored on the system before the SODELETE Job is eligible to delete them. The SODELTE Job runs under the
alias DELDEFAULT in the SYSTEM Process Flow. For more information on the SYSTEM Process Flow, see the
Administration Guide.
 Applications Manager 9.4.1

There may be times when you wish to override the Retention days setting specified at the Job level for every Job
in a Process Flow. For more information on the Retention days setting for Jobs, see Specifying Output Options for
Jobs.
For example, assume the retention days are set to 7 in the definitions of every Job in a Process Flow named
QUARTERLY, but you wish to retain their output files for 90 days. You cannot simply edit the Retention days setting
at the Job level, because the Jobs run in several other Process Flows.

You override the Retention days setting for every Job in a Process Flow by adding the
RESET_FLOW_RETENTION_DATES Job as the last component of that Process Flow as shown above.
The RESET_FLOW_RETENTION_DATES Job is included in an import file named
reset_chain_retention_dates.exp. For information on importing, see Opening Imports and Mapping Objects.
The RESET_FLOW_RETENTION_DATES Job includes two prompts. The first prompt uses the {chain_id}
Replacement Value to uniquely identify the Process Flow. The second prompt overrides the retention days. Its
default value is 60 days.

Introduction to Process Flow Building

After creating a Process Flow, the next step is to add components. It is the components in a Process Flow that
accomplish work. Process Flow components are added on the Components tab of the Process Flows window.
The image below shows a Process Flow with five components.
 Applications Manager 9.4.1

When you create a new Process Flow and select the Components tab for the first time, Applications Manager
displays an empty box for the Process Flow, along with the floating Jobs/Process Flows window.
Predecessors Control How a Process Flow Runs
Applications Manager relies on predecessor links to determine execution order. By default, when you add a
component to a Process Flow, it is added with a success predecessor link. The arrows between the components
on the Components tab represent predecessor links. The components execute as you would expect from looking
at the diagram: execution starts at the top and works down to the bottom. Components in the same row are eligible
to execute at the same time. You can move components left and right within a row using the <and > buttons (for
esthetic purposes only).
To display all the predecessor links in a Process Flow, click the mouse on a blank area in the Process Flow. To
display the predecessor links for a specific component, select the component.
 Applications Manager 9.4.1

In previous versions of Applications Manager, Process Flow execution order was determined by the sequence
of the components in the Process Flow and the components' single or multi-threading. Beginning with v6.0,
predecessors completely replaced those features.
Unlimited Predecessor Possibilities
Predecessors are used to graphically build Process Flows; you can also use them to create complex dependences
within and outside of Process Flows. The information in this chapter describes how to add components to a
Process Flow. When you add components, predecessor links are automatically added. Chapter Working with
Predecessors, details the predecessor execution rules and describes all predecessor features. To fully understand
how predecessors requirements are satisfied and how to set up complex predecessor scenarios, read that chapter.
Getting Started with Process Flows
To get started, select a Job or Process Flow from the Jobs/Process Flows window and drag it into the box on the
left that represents your Process Flow. When you add a second Job to the Process Flow, you decide whether you
want it to be run by itself in the Process Flow or be eligible to run with first Process Flow component.
To make a Job run by itself in the Process Flow, add it below the existing components on its own line. In the image
above, the FTP and REPORT_SUMMARY Jobs will run by themselves in the process flow.
To allow a component to run with other components, add it to the same row. In the image above, Jobs A and B are
allowed to run concurrently.
When dragging Job or Process Flows into a Process Flow, Applications Manager draws a blue border around all
components to which it will create a predecessor link, and a green border around all components to which it will
create a successor link.
When you add one or more components, a triangle is displayed on the Components tab to signify unsaved
changes. To save changes, click the Apply button. For more information on updating unsaved changes, see
Updating Unsaved Changes.
For more information on Process Flow building, see Adding Process Flow Components.

Working with Process Flows

Use the Components tab to add components to a Process Flow. It is the components in a Process Flow that
accomplish work. Components can include both Jobs and Process Flows. You can add up to 999 components to a
Process Flow. The image below shows a Process Flow with five components.
 Applications Manager 9.4.1

The Components tab includes two panes:

• The left pane is the Process Flow drawing area. It shows a graphical display of the process flow.
• The right pane displays sub-tabs where you specify information about each component in the Process Flow.
This is referred to as the Process Flow Details pane. For information on the Process Flow Details pane, see
chapter Editing Process Flow Component Information.
The two panes can be resized by dragging the splitter bar, or by clicking the arrows at the top of the splitter bar.
You can change the size of the image using the Scale slider.
As you move the mouse pointer over an object, the name of the object is displayed in the title bar of the Process
Flows window.
Invalid Predecessor References
 Applications Manager 9.4.1

If for some reason a Process Flow contains invalid predecessor references, a pop-up window alerts you to which
predecessor links need to be updated.
Displaying Predecessor Links
To display all the predecessor links in a Process Flow, click the mouse on a blank area in the Process Flow. To
display the predecessor links for a specific component, select the component.
Undoing and Redoing Actions
To reverse one or more actions, go to the View menu of the Components tab and select Undo. To redo actions,
select Redo. If you rename a Process Flow component, the memory of all actions is reset for undoing and redoing.
Flow Diagram Legend
The legend describes the graphics used in the flow diagram. To display the legend, click the Legend button in the
menu bar. To close the Flow Diagram Legend window, click the X in the title bar.
Printing the Process Flow Diagram
The following four print options are available from the File menu on the Components tab:
• Print Setup
• Print Preview
• Print
• Print All of Flowchart

Sizing and Aligning the Process Flow Display

The following items on the Component tab's View menu allow you to customize the size and select a horizontal or
vertical alignment for the Process Flow display:
• Full Screen
• Fit to Size
• One Time Fit to Size
• Show Horizontal/Show Vertical
The Fit to size and Show Horizontal/Show Vertical options can be saved for your workstation by selecting Save
Preferences from the File menu. For more information, see Saving Preferences for Creating Predecessors.
Full Screen
The Full screen command opens the Process Flow builder full screen window shown below. The Process Flow
builder full screen window includes only the menu from the Components tab and the flow diagram of the Process
Flow. It fills all available space and provides the maximum amount of working area.
 Applications Manager 9.4.1

The Process Flow builder full screen window allows the maximum amount of working area.
When the Process Flow builder full screen window is open, you cannot access the other Component sub-tabs.
To access the other Component sub-tabs, open the View menu and choose the Shared screen command.
Fit to Size
The Fit to size command scales objects in the Process Flow so they fill the viewable space. Applications Manager
will continue to scale the Process Flow as additional components are added.
One Time Fit to Size
The Fit to size one time command scales objects in the Process Flow so they fill the viewable space without
resizing as additional components are added.
Show Horizontal/Show Vertical
The Show Horizontal/Show Vertical flip-flop command controls how a Process Flow is displayed.
The Show Vertical command displays Process Flow execution order from top to bottom. Components eligible to
execute at the same time are displayed in the same row as shown below.
 Applications Manager 9.4.1

The Show Horizontal command displays Process Flow execution order from left to right, as shown below.

Customizing Predecessor Link Displays

The following items on the Component tab's View menu allow you to customize the predecessor links:
• Draw squared arrows
• Show arrows as successors
The Draw squared arrows and Show arrows as successors options can be saved for your workstation by
selecting Save Preferences from the File menu. For more information, see Saving Preferences for Creating
Predecessors.
Draw Squared Arrows
When the Draw squared arrows option is selected, Applications Manager uses right angles to draw predecessor
links between components that are in adjacent levels. Diagonal lines are still used for components that are not in
adjacent levels and for predecessor links to components inside a group. If the Draw squared arrows option is not
selected, Applications Manager uses diagonal lines for all predecessor links as shown below.
 Applications Manager 9.4.1

If you are creating relatively simple Process Flows, squared arrows may be your best choice. If you are creating
complex Process Flows with many components, the diagonal arrows are a better choice.
Show Arrows as Successors
When the Show arrows as successors option is selected, Applications Manager points the arrow heads towards
the successor. If the Show arrows as successors option is not selected, Applications Manager points the arrow
heads towards the predecessor. In the image below, the latter is the default setting.

Controlling Process Flow Display Options

The following items on the Component tab's Options menu allow you to control how Process Flow building works:
• Prompt for alias name
• Shaded background
• Show predecessors
• Show all dependencies
• Show no dependencies
The Prompt for alias name, Shaded background, and Show predecessors options can be saved for your
workstation by selecting Save Preferences from the File menu. For more information, see Saving Preferences for
Creating Predecessors.
Prompt for Alias Name
In Applications Manager, you can add multiple copies of the same Job or Process Flow to a Process Flow.
However, each component you add must have a unique alias name. The Prompt for alias name option
determines if the window shown below is displayed when you select a component from the Jobs/Components
window and drag it into a Process Flow.
 Applications Manager 9.4.1

The window gives you the opportunity to change the alias name of the component.
There are three settings for the Prompt for alias name option:
• Always: The window is always displayed. This is the default setting.
• Only for duplicates: The window is displayed only if the component is already included in the Process Flow.
The window gives you the opportunity to enter a unique alias name.
• Never: The window is never displayed. If the component already exists in the Process Flow, Applications
Manager will automatically add a "_01" type number to the end of the alias name to create a unique alias.
The option you select will be used for the current Process Flow only.
Shaded Background
The Shaded background option helps to set apart nested Process Flows as shown below. Applications Manager
cycles through three shades as needed to accommodate the nested levels.
 Applications Manager 9.4.1

Show Predecessor Types

You can select the types of predecessor links that are displayed.
Show All Dependencies
Shows all predecessor links. Places a check mark in all options on the Show predecessors menu.
Show No Dependencies
Hides all predecessor links. Unchecks all options on the Show predecessors menu.

Adding Process Flow Components

To add components to a Process Flow, you open the Jobs/Process Flows window shown below, select a
component, and add it to the Process Flow. Applications Manager automatically creates one or more default
success predecessor and successor links, depending on your component selection or placement.
 Applications Manager 9.4.1

To display the Jobs/Process Flows window, click the Jobs/Process Flows selector window icon in the menu bar.
Using the Jobs/Process Flows Window
There are several features in the Jobs/Process Flows window that make adding components easier:
• You can select an Application from the Application field to display only components that belong to that
Application.
• If you want more or fewer items displayed in the Jobs/Process Flows window, you can resize the window by
dragging their borders.
• You can type letters into the Search field to filter the list.
• You can select multiple components using the Shift+click and Ctrl+click key-mouse combinations.
 Applications Manager 9.4.1

Two Ways to Add Components

There are two ways to add components to a Process Flow. You can:
• Drag and drop single Jobs and Process Flows from the Jobs/Process Flows window.
• Select one or more Jobs on the Jobs/Process Flows window and add them to the Process Flow using the Add
components buttons at the bottom of the window.
Changing Process Flow Component Predecessors
You can perform the following types of edits to Process Flow components:
• Move the components to a new location by dragging and dropping. When you drag a component to a new
location, all existing internal predecessor links are broken.
• Add new predecessor links.
• Change a predecessor link type.
• Delete components and predecessor links.
For more information on editing and deleting Process Flow components, see Arranging Components in a
Process Flow. For information on updating component definitions, see chapter Editing Process Flow Component
Information.
Moving Components Left and Right
You can move components left and right within a row using the < and > buttons (for esthetic purposes only).

Adding Components Using Drag-and-Drop

If you are building a relatively small Process Flow, one with 10 to 20 components, for example, one of the easiest
ways to build the Process Flow is to drag and drop components from the Jobs/Process Flows window shown
below.
 Applications Manager 9.4.1

When you drag a Job or Process Flow into a Process Flow, Applications Manager draws a blue border around
all components it will create a predecessor link from, and a green border around all components it will create a
successor link to.
It is useful to think of a Process Flow diagram as being divided into rows. Components that share a row are eligible
to run together. Components in separate rows will run by themselves within the process flow.
If you attempt to move a component outside the parent Process Flow, or to any other location where it cannot be
placed, the pointer changes to a "not allowed" symbol (circle with a line through it), indicating that you cannot drop
the component at that location.
When you nest a Process Flow inside another Process Flow, you cannot edit the nested Process Flow. However,
you can create predecessor links to and from the components within the process flow.
Procedure
To add a component using drag-and-drop:
 Applications Manager 9.4.1

1. Select a Job from the Jobs/Process Flows window.

When selecting a Job/Process Flow, you can type the first few letters of its name in the Search field and
Applications Manager will find it. The Search field accepts valid regular expressions. For information on the
syntax for regular expressions, see Appendix A: Regular Expression Tables.
In the image above, the REPORT_DETAILED Job is selected.
2. Hold down the left mouse button and move the selected Job or Process Flow to the appropriate area of the
Process Flow's box

Adding Components Using the Add Buttons

In Adding Components Using Drag-and-Drop, you saw how to add components using drag-and-drop. This is a fast
way to add components, with Applications Manager automatically creating the predecessor links based on where
you drop the components. If you want greater control over the predecessor links, use the add buttons at the bottom
of the Jobs/Process Flows selector window.

Multiple Selections
When you use drag-and-drop to add components to a Process Flow, you can generally add one component at a
time. An advantage to the add buttons is that you can easily add many components at one time.
Add Buttons
 Applications Manager 9.4.1

The Jobs/Process Flows selector window includes four buttons that determine which type of predecessor link
Applications Manager will create when you add a component to the Process Flow. Initially, Applications Manager
creates success predecessor links. You can change these later if you wish.

Button Description

Successor Applications Manager adds the component with

predecessor links to all selected components. If the
components selected are in more than one row, the new
component will be placed below the lowest row.

Clone Applications Manager adds the component using the

predecessor links defined for all selected components.
If the components selected are in more than one row,
the new component will be placed with the objects in
the lowest row.

No preds Applications Manager adds the components in the

upper right corner of the Process Flow in the top row,
without any predecessor links.

External Applications Manager adds the components to the

External References window with predecessor links
to all selected components. For more information on
external links, see Adding Internal Predecessor Links in
Process Flows.

Procedure
To add one or more components to a Process Flow using the add buttons:
1. If appropriate, select one or more existing components in the Process Flow.
2. Select one or more components in the Jobs/Process Flows window.
For multiple selections, use the Shift+click and Ctrl+click key-mouse combinations.
3. Enter the number of copies (if more than one).
Multiple copies of a component are added in the same row.
4. Click the appropriate add button: Successor, Clone, No preds, or External.
Applications Manager adds the components to the Process Flow with default success predecessor links.

Arranging Components in a Process Flow

To move a component to a new location in a Process Flow, select the component and drag it to the new location.
You must use the mouse to move components. You cannot perform this action with the keyboard.
Moving a Components
When you move a component, internal predecessor links are changed to maintain a logical flow. External
predecessor links are not changed. You can move components left and right within a row using the < and > buttons
(for esthetic purposes only).
 Applications Manager 9.4.1

Moving a Group of Components

When you move a group of components, predecessor links are broken and new links are established based on
where you drop the components. External predecessor links are not changed.
To move a group of components:
1. Select the components by doing one of the following:
• Click and drag across the components.
• Hold down the Ctrl key and click on each component.
Selected components are highlighted with blue borders.
2. Drag the components to the new location.
The drop point is determined by the location of the mouse pointer, not the location of the components.
Deleting Components
When you delete a component from a Process Flow, the next component in the Process Flow inherits the
predecessor links of the deleted component. To delete a component, select the component and either:
• Right-click and select Delete.
• From the Edit menu and select Delete.
You can select more than one component to delete at a time by clicking and dragging or using Ctrl and Shift clicks.
Components cannot be deleted from a Process Flow while they exist in the Backlog. However, you can inactivate
components in a Process Flow that is in the Backlog or remove any of their predecessors. This will affect later runs
of the Process Flow, but not tasks currently in the Backlog.
Finding a Component
If you are working with a large Process Flow, you may not recall the location of a particular component. You can
jump to the component using the Find component feature.
To find a component:
1. Open the Find Alias window by choosing Find component from the Edit menu.
 Applications Manager 9.4.1

Applications Manager opens the Find Alias window shown below.

2. Enter a Job or Process Flow name.

You can enter partial text in this field, but you cannot use wildcards.
3. Choose either the Search up or Search down option for the Process Flow.
4. Initiate the search by clicking Find next.
You can search for another instance of the text in the Process Flow by clicking Find next again.
When you have completed your search, close the Find Alias window by clicking Cancel.
Renaming a Component Alias
You can change alias names in the Alias field on a component's General tab, or by right-clicking a Job or Process
Flow in the flow diagram. When you rename a Process Flow component, the memory of all actions is reset for
undoing and redoing.
Updating Component Definitions
After arranging your components, you can select the sub-tabs in the Process Flow Detail pane to update each
component. For information on updating component definitions, see chapter Editing Process Flow Component
Information.

Creating Component Groups

There may be times when you want to logically group components within a Process Flow without creating a sub-
Process Flow. For example, suppose you wanted to create the Process Flow shown below
 Applications Manager 9.4.1

Component groups are logical groupings that exist only within a Process Flow. They can be expanded and
collapsed to simplify large diagrams.
Rules Governing Groups
The following are the key rules governing the behavior of groups:
• Any number of groups can be added to a Process Flow.
• Groups cannot be nested, however you can add a Process Flow that contains groups to another Process Flow.
• You can add and delete components from groups using the same procedures you use to add and delete
components from a Process Flow. For information on adding and deleting components from a Process Flow,
see Adding Process Flow Components.
• When you add a component to a group using the Jobs/Process Flows window, you must select a predecessor
within the group. You cannot select the group.
• You can drag Process Flow components into and out of a group.
 Applications Manager 9.4.1

• Group position is determined by the predecessor links to components outside the group.
• You cannot assign predecessor links to groups, only to components within groups.
• Groups are saved with the Process Flow.
• You cannot drag and drop a group. If you want to move a group, you can redirect its predecessors.
Collecting Components into a Group
To collect components into a group:
1. Select the components by doing one of the following:
• Click and drag across the components.
• Hold down the Ctrl key and click on each component.
Selected components are highlighted with blue borders.

2. Select Group from the Edit menu.

The components are grouped to show a better parallel flow.
 Applications Manager 9.4.1

Deleting Groups
When you delete a group, the group is removed, but the components remain. To delete a component group:
• Right-click the group and choose Delete.
• Highlight the group, then from the Edit menu, choose Delete.

Navigating Large Process Flows

There may be times when you need to edit large Process Flows. When this happens, it can be hard to tell what part
of the Process Flow you are viewing. With the Navigator window, you can see what part of the Process Flow you
are looking at and move to components in other parts of the Process Flow.

Procedure
 Applications Manager 9.4.1

To display the Navigator window, click the Navigator button in the menu bar. From the Navigator window shown
above, select the handle with your mouse and move it to navigate through the Process Flow. When you move the
handle, the cyan box represents the part of the Process Flow currently displayed.

Implementing Process Flow Component Change Revisions

Change revisions allow you to make edits to one or more Process Flow components and update the Process Flow
with these revisions at a later time. To revise a Process Flow you:
• Replicate and edit one or more Process Flow components.
• Implement changes when ready, based on suffixes assigned to replicated components.
Replicating and Editing Components
To replicate a Process Flow component:
1. From a Process Flow's definition, right-click the component you wish to replicate.
Applications Manager displays the pop-up menu shown below.

2. From the pop-up window, click Replicate.

Applications Manager opens the Replicate id window shown below.

3. On the Replicate id window, enter a suffix for the replicated component and click OK. In the example above,
the suffix REV2 is entered.
The new component is added to the same level as the original component. It will be named <original alias>--
<suffix>. In the image below, the replicated component is named DATA_CLEANSE--REV2. By default,
 Applications Manager 9.4.1

its Component active box will be unchecked. All other values from the General, Output, Prompts,
Predecessors, Conditions, and Documentation sub-tabs will be identical on the new Process Flow
component.

If you replicate additional components, the suffix entered for the first replicated component will automatically be
added in the Replicate id window.
External predecessor links from other Jobs and Process Flows to the original component will not be created
for the replicated component. However, predecessors from the replicated components to external Jobs and
Process Flows are copied.
4. Edit the Process Flow component's details. As long as the replicated component is inactive, the changes will not
affect the running of the Process Flow.
You can replicate and edit additional components in the Process Flow. If you wish to implement changes to two
or more components at once, use the same suffix.
Make sure you do not edit the alias name of the original or replicated Process Flow components. They must
match when you implement change revisions.
Implementing Change Revisions
When you are ready to implement change revisions do the following:
1. If you want to make a back-up of the Process Flow before implementing changes, export the Process Flow. For
information on exporting and importing, see chapter Exporting and Importing Objects.
2. Select Implement Change Revision from the Edit menu.
Applications Manager opens the Change Revision window shown below.
 Applications Manager 9.4.1

3. In the Change Revision window, enter the suffix of the component(s) you wish to implement changes for and
click OK. In the image above, the suffix REV2 is entered.
Applications Manager removes the original components and replaces them with any replicated/edited Process
Flow components that include the specified suffix. The suffix is removed from the alias when this change is
made.

Viewing a Gantt Chart of the Process Flow

The Components tab shows a Process Flow as a flow diagram. When you want to look at the expected execution
time for the Process Flow as a whole, and the execution times of the individual components in the Process Flow,
you can display the Gantt view shown below.

To view a Gantt chart of the Process Flow, click the Gantt view icon on the Components tab. The Gantt view
displays a tree view of the Process Flow in the left pane, and the Gantt chart in the right pane. To view a Gantt
chart of the Process Flow, click the Tree view icon on the Components tab.
Actions
You can take the following actions on the Gantt view:
• You can expand and collapse the elements in the tree by clicking the toggle icons.
• You can scroll the Gantt chart using the scroll bar at the bottom of the right pane.
• You can change the hours displayed in the Gantt chart by selecting a value from the Visible Hours field. The
range is 1 to 24 hours.
You cannot add, edit, or delete components from the Gantt view.
Options
There are several options available from the Options menu. They are described below.
• Print table/Print preview table/Print tree/Print preview tree
These four options are used to preview and print the tree and the Gantt chart.
• Expand/Collapse
These two options are used to expand and collapse a selected component in the tree.
• Base time on external references
If the Process Flow has external references, you can set the start times for the Gantt chart to them.
• Enter start time for Gantt chart
 Applications Manager 9.4.1

The default start time for a Gantt chart is midnight of the current day. If the Process Flow is scheduled to start
at a specific time of the day, you can change the start time using this feature so it matches the scheduled start
time.
• Reset start time to midnight
Resets the start time for the Gantt chart to midnight.

Calculating Process Flow Average Run Times

The non-editable Ave run time field stores the average run time for a Process Flow when you calculate it. This
value returned in the Ave run time field is informational only.

To: Click:

Return the sum of the average run times of the Estimate.

components in the Process Flow's critical path

Calculate average run times based on History Calculate.

Estimating to Get the Critical Path

To return the sum of the average run times of the components in the Process Flow's critical path, click Estimate.
This time will match what is shown for the Process Flow's run time in the Gantt charts on the Backlog Gantt View,
History Gantt View, Graphical Forecast, and Process Flow Gantt View windows.
Calculating Average Run Times Based on History.
To calculate average run times based on History, you use the Calculate button shown below.
 Applications Manager 9.4.1

Clicking the Calculate button opens a window where you enter start and end times. You can use the Calendar
icons to select these times from a Calendar window. Once you select dates and click OK, the window closes and
Applications Manager opens the window shown below.
 Applications Manager 9.4.1

If you want, you can double-click a row to view details for the Process Flow's components for that run of the
Process Flow.

Editing Process Flow Component Information

After creating a Process Flow, you can specify how each component will run. You select its eligible run days and
execution options, and define special run conditions.
 Applications Manager 9.4.1

Setting Aliases for Process Flow Components

Using the Alias field, you can give an alternate name to a Process Flow component. This gives you a way to
distinguish multiple instances of the same Job or Process Flow added to a Process Flow. For example, you might
use a Job twice in a Process Flow, each with a different set of values entered for the prompts. Aliases replace
the Job/Process Flow name in the Backlog and History. The default alias for a component is its Job or Process
Flow name. You can change alias names in the Alias field, or by double-clicking a Job or Process Flow in the flow
diagram. When you rename a Process Flow component, the memory of all actions is reset for undoing and redoing.
Do Not Use {module} or {task} in Alias Names: Make sure you do not use the {module} or {task} Replacement
Values in alias names. Doing so leads to circular references where Tasks get stuck in Pred Wait status.
Activating and Inactivating Process Flow Components
 Applications Manager 9.4.1

You can inactivate a Process Flow component by unchecking the Component active option in the upper right
corner of the pane. This can be useful if you are building a Process Flow and want to test some Jobs or Process
Flows but not others. An inactive Job/Process Flow will be displayed in gray in the Process Flow diagram.
When the Process Flow runs, the component will be inserted into the Backlog with a PW-SKIP status. Although the
component does not run, its predecessors are still evaluated and it can be a predecessor to other tasks. When the
task is removed from the Backlog, a record is written to History with an Skip!Active status.
Adding Documentation to Process Flows and Process Flow Components
Use the Documentation sub-tab to enter relevant information about the processing of a component. By selecting
an individual task in Explorer and choosing Documentation, operators can access the comments, suggestions, or
instructions for an individual task. Documentation includes general and abort categories and can be formatted in
plain text or HTML.
You can enter customizable general and abort documentation for Jobs, Process Flows, and Process Flow
components. For more information, see Adding Job Documentation.
Specifying Process Flow Component Options
Use the General, Output, and Prompts sub-tabs for the following tasks in this chapter:
• Specifying Calendars and Eligible Run Days
• Setting Execution Options
• How Agent Assignments Are Handled for Process Flow Components
• Specifying Output Devices
• Specifying Prompt Values
Tasks on the Predecessors, Conditions, and Documentation tabs are described topics outside of this chapter:
• Working with Predecessors
• Working with Conditions
• Adding Job Documentation
See Also
• Adding Process Flow Components

Specifying Calendars and Eligible Run Days

If you are building a Process Flow with a number of different components, you may want a component to run only
on certain days of the week even though the Process Flow runs every day. Or you may want a component to run
on or skip the days specified in a Calendar. You can do both with the Eligibility box on the General sub-tab for a
Process Flow component.
 Applications Manager 9.4.1

Using a Calendar
To use a Calendar to determine the eligibility of a component within a Process Flow:
1. From the General sub-tab, select a Calendar from the Calendar drop-down list box
2. Choose an option:
• Run: Allows the component to run on the days specified in the Calendar, provided the Calendar days fall on
one of the days of the week selected for the component.
• Skip: Prevents the component from running on the days specified in the Calendar.
3. If applicable, uncheck the days of the week that you do not want the component to be eligible to run.
Specifying Eligible Days of the Week
 Applications Manager 9.4.1

Regardless of whether a Process Flow component is assigned to a Calendar, you can specify the days of the week
it is eligible to run. Uncheck the days of the week that you do not want this component to run. The component will
not run on these days when the Process Flow is scheduled or requested on an ad hoc basis.
If you do not want any of the components in a Process Flow to run on a particular day of the week when the
Process Flow is scheduled, remove that day from the Process Flow's schedule. For more information on setting
Process Flow schedules, see chapter Scheduling Jobs and Process Flows.
Determining Days by the Virtual Workday
The virtual workday is used to establish the reset time for all external predecessor links. For detailed information on
the virtual workday, see Understanding the Virtual Workday.
If the Use virtual day for Process Flow component days of week Automation Engine option is selected, all
component scheduling for skip Calendars and eligible days of week will be determined by the current virtual
day. For example, if the virtual day is set to 8:00 P.M., the current day will be considered Tuesday from 8:00
P.M. Tuesday until 7:59:59 on Wednesday. You might want to use this feature if you have Process Flows that
start running before midnight, but particular components might not start until the next Calendar day. For more
information on setting Automation Engine options, see the Administration Guide.
If the Use virtual day for Process Flow component days of week setting is selected for the Automation Engine,
tasks cannot be staged beyond 24 hours from the start of the virtual day.

Setting Execution Options

Use the execution options to control how and where the component executes. You can define the execution options
for each Process Flow component on the General sub-tab.
 Applications Manager 9.4.1

The execution options are described below.

• Agent
If the Job referenced by this Process Flow component is assigned to an Agent Group, you can select an Agent
from the group (only the Agents in the group will be listed). The task will run on the Agent assigned here. If 'No
selection' is picked, the task will run on the Agent selected on the Process Flow's General tab. If 'No selection'
is picked there as well, or the Agent is not available in this component's Agent Group, one of the following will
happen:
• For regular Agent Groups: The component will use the load balancing algorithm for the Agent Group.
• For multi-execution Agent Groups: The component will run on each Agent in the multi-execution Agent
Group.
For more information, see How Agent Assignments Are Handled for Process Flow Components.
• Login
 Applications Manager 9.4.1

Designates the Login to be used to access the server or database required by the program. This overrides the
Login set in the Job definition. You will only be able to select a Login if one was included in the Job definition.
• Output Scan
Scans output for text strings. Depending on the rules of the Output Scan, the Job will fail or succeed when it is
found. For information on defining the rules of an Output Scan, see Defining Output Scans.
• Notification
Optionally use Notifications to send messages and output files based on task status to email addresses or
any Output Device defined in Applications Manager. For information on defining Notifications, see Defining
Notifications.
• Environment Variables
Specifies one or more Environment Variables as a single Applications Manager object. For information on
defining Environment Variables, see Defining Environment Variables.
• Ave run time
Stores the average run time for the component (DDD:HH:MI). You can either manually enter a value in this
field, or run the AW_CALC_AVE_RUN_TIMES_1 Job to populate it. For more information, see Running the
CALC_AVE_RUN Job. This time will be displayed in the Gantt charts on the Backlog Gantt View, History
Gantt View, Graphical Forecast, and Process Flow Gantt View windows.
• Use Request Output Device
If this option is selected, Applications Manager overrides the print settings for the Process Flow component with
the settings specified on the Output tab of the Process Flow. For more information on the Output tab of the
Process Flow, see Specifying Output Options for Process Flows.
The Output sub-tab for the component in the Process Flow will be grayed and not available for selection.
If the Process Flow is requested on an ad hoc basis, you can override the print setting from the Submit window.
• Use Job Conditions
If this option is selected, the component will use the conditions defined in the component's (Job or Process
Flow) definition. The Conditions tab for the component in the Process Flow will be grayed and not available for
selection.
Specifying a Component's Queue
Unless the Insert components into process flow's queue Automation Engine option is selected, Process Flow
components will run on the Queue specified in their Job definition. For more information on setting Automation
Engine options, see the Administration Guide.
If you want to override the Queue for a particular Process Flow component, you can specify it using a BEFORE
condition with a CHANGE Q action. For an example, see Entering Execution Options for Process Flows.

How Agent Assignments Are Handled for Process Flow Components

If a Process Flow component references a Job, and that Job is defined to run on an Agent Group, you can select
an Agent from the Agent drop-down list box on the General sub-tab. The Agents displayed in the drop-down box
will be the Agents that belong to the Agent Group assigned to the Job. If you select an Agent from this field, the Job
will execute on the selected Agent. It does not matter if the Agent Group is regular or multi-execution.
If 'No selection' is picked, the task will run on the Agent selected on the Process Flow's General tab. If 'No
selection' is picked there as well or the Agent is not available in this component's Agent Group, one of the following
will happen:
• For regular Agent Groups: The component will use the load balancing algorithm for the Agent Group.
• For multi-execution Agent Groups: The component will run on each Agent in the multi-execution Agent
Group.
If the Job is defined to run on a single Agent rather than an Agent Group, the Agent field on the component's
General sub-tab will have no bearing on where the Job will execute. Only the 'No selection' option will be displayed
in the Agent drop-down list.
If a Process Flow component references a Process Flow, you can select an Agent from the Agent drop-down list
box on the General sub-tab. The Agent you select for the sub Process Flow will be used the same as any other
Process Flow's Agent.
Order of Precedence for Process Flow Agent Assignments
 Applications Manager 9.4.1

The order of precedence for assigning Agents to Process Flows is:

1. The request or schedule Agent
2. The Process Flow's default Agent
3. The APPWORX_AGENTS Agent Group
Order of Precedence for Component Agent Assignments when Components Are Jobs
The order of precedence for assigning Agents to components that reference Jobs is:
1. The Job's Agent
2. The component's assigned Agent on the General sub-tab under Components in the Process Flow definition
(allowed only if the Job is assigned to an Agent Group in its Job definition)
3. The component parent Process Flow's Agent
Order of Precedence for Component Agent Assignments when Components Are Sub Process Flows
The order of precedence for assigning Agents to components that reference sub Process Flows is:
1. The component's assigned Agent on the General sub-tab under Components in the Process Flow definition
2. The Agent selected in the component's referenced Process Flow definition
3. The component parent Process Flow's Agent
4. The APPWORX_AGENTS Agent Group
Example: Selecting an Agent for Process Flow Components that Reference Jobs
Assume you define JOB_A to run on AGENT_GROUP_1. AGENT_GROUP_1 is a regular Agent Group.
AGENT_GROUP_1 includes three Agents: AGENT_ALPHA, AGENT_BETA, and AGENT_GAMMA. You add
JOB_A to PROCESS_FLOW_Z where you want it to run on AGENT_GAMMA. To accomplish this, you would
select JOB_A as a component in PROCESS_FLOW_Z, and from the Agent field on the component's General sub-
tab select AGENT_ALPHA.
Now assume you want to add several Jobs to PROCESS_FLOW_Z. All of the Jobs are assigned to
AGENT_GROUP_1. You want all of the Jobs to execute on AGENT_ALPHA. To accomplish this, you could select
AGENT_ALPHA on the General sub-tab for each component in the Process Flow. Or you could leave the Agent
for each Job set to 'No selection', go to the General tab of the Process Flow, and select AGENT_ALPHA from the
Default agent field.
Agent Use Tables
The tables below describe the effects of selecting Agents, regular Agent Groups, and multi-execution Agent Groups
in various fields.
When an Agent is selected in a component's Job definition...

The component's Agent: And the Process Flow's default The effect is:
Agent is:

Cannot be changed Any Agent or 'No Selection' The component runs on the Job's
selected Agent.

A multi-execution Agent (can be The Process Flow is run for every

overridden by an ad hoc request or Agent in the Agent Group.
schedule)
This component runs in every
Process Flow, but always on the
same Agent.

When a regular Agent Group is selected in a component's Job definition...

The component's Agent: And the Process Flow's default The effect is:
Agent is:

Is an Agent from the Job's Agent Any Agent or 'No Selection' The component runs on its selected
Group Agent.
 Applications Manager 9.4.1

The component's Agent: And the Process Flow's default The effect is:
Agent is:

A multi-execution Agent (can be The Process Flow is run for every

overridden by an ad hoc request or Agent in the Agent Group.
schedule)
This component runs in every
Process Flow, but always on the
same Agent.

Is 'No Selection' An Agent from the Job's Agent The component runs on the Process
Group (can be overridden by an ad Flow's selected Agent.
hoc request or schedule)

'No Selection' or a selected Agent The Agent Group's load balancing

not in the Job's Agent Group equation is used.

A multi-execution Agent (can be The Process Flow is run for every

overridden by an ad hoc request or Agent in the Agent Group.
schedule)
This component runs in every
Process Flow, on each Agent.

When a multi-execution Agent Group is selected in a component's Job definition...

The component's Agent: And the Process Flow's default The effect is:
Agent is:

Is an Agent from the Job's Agent Any Agent or 'No Selection' The component runs on its selected
Group Agent.

A multi-execution Agent (can be The Process Flow is run for every

overridden by an ad hoc request or Agent in the Agent Group.
schedule)
This component runs on the
selected Agent for the component in
each Process Flow.

Is 'No Selection' An Agent from the Job's Agent The component runs on the Process
Group (can be overridden by an ad Flow's selected Agent.
hoc request or schedule)

'No Selection' or a selected Agent The component is run on every

not in the Job's Agent Group Agent in the Agent Group.

A multi-execution Agent (can be The Process Flow is run for every

overridden by an ad hoc request or Agent in the Agent Group.
schedule)
This component runs on every Agent
in its Agent Group.

Specifying Output Devices

You can specify target Output Devices for the output of a component from the Output sub-tab. This setting
overrides the output settings for the Job. Output will be sent to all Output Devices listed on the Process Flow
components' Output sub-tab. The output options are described in Table A.
 Applications Manager 9.4.1

The settings on this sub-tab can be overridden if the Use Request Output Device option on the Process Flow
components' General sub-tab is selected. When the Output Use Request Output Device option is selected, the
Output sub-tab is grayed out.
Adding Output Devices to a Component
To add an Output Device to a component:
1. Select the Output sub-tab for a component as shown above, and click the New button.
Applications Manager opens the Printer window shown above.
2. Complete the fields using the information below.
• Output Device
The Output Devices you can select here are limited to those in the Job's Output Group.
• Output Option
 Applications Manager 9.4.1

Allows users to select a specific variable, setting, address, or orientation. This field appears only when a
variable output option has been defined for the selected Output Device.
• Output Function
Determines how output is handled. With any of these settings, the application output or report files and the
system output files are viewable from the Explorer window. There are three choices:
• LOG: Legacy setting, should not be used unless you need to use the Output window rather than the
Explorer window. Applications Manager loads all application output or report files for viewing in the
Output window for tasks with a LOG output function every time a User logs into the client. This can take
several seconds or minutes. If more than 500 files are loaded, an alert will be displayed. Therefore, if
users are not using the Output window (that is, they view output from History instead of the Output
window, or output is emailed to them), you should use the STORE setting.
• PRINT: The output is printed.
• STORE: The output is not printed.
• User
All user names are available for this field. The name you select will be displayed in the banner of reports if
the -t %USR% option was specified in the Title field in the Output Interfaces window.
• Copies
Specifies the number of copies to print if a printer is selected as the Output Device (1-99).
• Available On
Select the days you want the Output Device to be available. This can be useful if you want the output
generated by the component to be sent to one group of people on one day, and to another group of people
on another day. For example, you might want a sales report sent to an area office Output Device every day,
but to a regional office Output Device only on Fridays.
3. To save the settings and add the Output Device to the component, click OK.
Applications Manager adds the Output Device to the list displayed at the top of the Output sub-tab.
Updating and Deleting Output Devices
To update or delete an Output Device, select the Output Device from the list at the top of the Output sub-tab and
click Edit or Delete.

Specifying Prompt Values

When you run a Job or Process Flow on an ad hoc basis, you can enter values for the prompts in the Submit
window. For Process Flow components, you must enter values for the prompts from the Prompts sub-tab. This
topic presents a brief discussion of prompts. For a detailed discussion of prompts, see chapter Adding Prompts to
Jobs and Process Flows.
 Applications Manager 9.4.1

The Prompts sub-tab displays a table that lists the prompts defined for the Job or Process Flow. The table includes
the following columns:
• #: The order of the prompts in the Job or Process Flow.
• Default: The prompt value defined in the Job or Process Flow definition.
• Description: The description for the prompt defined in the Job or Process Flow definition.
• Value: You can edit in this column to override prompt values.
If the prompt's data type allows you to select a value, the Select button will be active. A value entered here will
override the default value. Values allow the use of static, dynamic and numeric Subvars.
If you use Subvar(s) here, the prompt's max length setting will be ignored.
You can use multiple Subvars in the same value. When you do, be sure to enclose them in { } braces. For
example, {#1}{#2} or {#today}{#1}. You can pick static and dynamic Subvars using the { } button. To specify
a null value for a Process Flow component's prompt that includes a default value, enter two single quote
characters.
If you do not specify a prompt value, the component will use the default prompt value.
 Applications Manager 9.4.1

• Required: Indicates whether a prompt value (in either the Default or Value column) is required. If a value is
required for one or more Process Flow component prompts, and you do not provide them, a message will pop
up asking you to provide values or ignore them.

Working with Predecessors

Predecessor links are dependencies you add to components in a Process Flow, or to standalone Jobs. You can
create predecessor links.
• Automatically by building Process Flows.
• Manually by adding internal or external dependencies for Jobs, Process Flows, and Process Flow components.
When creating predecessor links, you determine the predecessor link type, which specifies its requirement and how
it integrates with the other predecessor tasks.
Automatically Adding Internal Predecessors by Building Process Flows
Applications Manager relies on predecessor links to determine execution order. By default, when you add a
component to a Process Flow, it is added with an internal success predecessor link as shown below.
 Applications Manager 9.4.1

The components execute as you would expect from looking at the diagram: execution starts at the top and works
down to the bottom. Components in the same row are eligible to execute at the same time. Internal predecessors
that are added by building Process Flows are the most commonly used and easily understood predecessors.
Manually Adding Internal Predecessors to Process Flow Components
After adding components to a Process Flow, you may want to create additional links within the Process Flow. This
is done by manually adding internal predecessor links. For more information, see Adding Internal Predecessor
Links in Process Flows.
Manually Adding External Predecessors to Jobs and Process Flows
You can also add predecessor links to Jobs, Process Flows, and Process Flow components outside the Process
Flow. These are called external predecessor links. In the image above, there is an external predecessor link to a
Job. You can create external predecessor links for a standalone Job from the Jobs window and for non-running
tasks in the Backlog. When you add external predecessor links to tasks in the Backlog, the predecessors are only
 Applications Manager 9.4.1

applied to that running of the task. They do not affect the Job or Process Flow definition. For more information on
external predecessor links, see Adding and Editing External Predecessor Links.
Specifying Predecessor Link Types
There are several types of predecessor links. The Success link is the default and is acceptable in the majority of
cases, but you may want to change the type. For example, you may want to change the link type to Failure to run a
task when another task fails.
Depending on the predecessor link type, the predecessor link will:
• Apply to tasks within a virtual day.
• Have no regard for the virtual day.
The only predecessor type that does not take the virtual day into consideration is the Success since last run type.
Since internal predecessors exist within the same Process Flow, they are by definition, within the same virtual day.
For this reason, the Success since last run link type is not available for internal predecessors. For more information
on predecessor link types, see Understanding Predecessor Execution Rules.
Predecessors are Evaluated Based on the Virtual Day
The virtual workday is a point in time each day that limits how far back Applications Manager will search in the
Backlog and History for a predecessor. A task's virtual day is determined by the original start time of that task, not
when the task is inserted into the Backlog.
Predecessors (other than Success since last run) are constraints within the same virtual day. A predecessor link is
considered met when the predecessor task is not scheduled to be run in that virtual day as long as the predecessor
has a schedule associated with it. When tasks are staged, their start time is set to their scheduled start time. For
more information on the virtual workday, see Understanding the Virtual Workday.
Integrating Multiple Predecessors
When a Job, Process Flow, or Process Flow component includes multiple predecessor links, you decide how they
work together. For more information on working with multiple predecessor links, see Using the Predecessor Editor
Box. An example of an advanced predecessor use case is described in Evaluating Predecessors on Select Days.

Understanding Predecessor Terminology

The terms below are used when discussing predecessors.
Predecessor: A Job, Process Flow, or Process Flow component that is a dependency for another task to run. In
the image below, the Process Flow component FTP is a predecessor of the DATA_LOAD component.

Predecessor link: The link from a Job, Process Flow, or Process Flow component to its predecessor. In the image
above, a green arrow represents the Success predecessor link from DATA_LOAD to FTP. The link type you select
for a predecessor dictates the requirements for when the task can run.
Successor: The task which runs based on its predecessor(s). In the image above, DATA_LOAD is the successor
of FTP.
Successor link: The link from a Job, Process Flow, or Process Flow component to its successor. In the image
above the same green arrow that represents the predecessor link from DATA_LOAD to FTP also represents the
successor link from FTP to DATA_LOAD. They are one and the same; the terms are just used in different contexts.
 Applications Manager 9.4.1

Understanding Predecessor Execution Rules

To ensure the correct execution of components in a Process Flow, it is important for you to understand how
Applications Manager handles predecessor links.
Predecessor links are critical to the execution of Applications Manager Process Flows. To become proficient at
creating Process Flows and adding predecessor links, you will need to understand how the following rules govern
the behavior of predecessor links in Applications Manager.
The behavior of some predecessor types may be slightly different than you might expect. For example, the
requirements of a success predecessor link are satisfied by things other than the predecessor task finishing with a
FINISHED status.
Also, it important to understand that Success and Failure predecessor links are not opposites. There is some
overlap between their requirements. For example, a Success predecessor link will be satisfied if its predecessor
task aborts and is removed from the Backlog, because its Stay in Queue on abort setting is turned off. A failure
predecessor link will also be satisfied in this same scenario, because ABORTED is a failure status.
 Applications Manager 9.4.1

Predecessor Status Groups

Use the following predecessor status groups to help you understand predecessor link requirements.
• The FINISHED status
A status of FINISHED may be displayed briefly in the Backlog when a task successfully completes its operation.
Assuming that the Automation Engine is up and running, FINISHED tasks in the Backlog will quickly move to
History.
• Ineligible statuses
Ineligible statuses signify that a task is no longer eligible to run. Ineligible statuses include: PW-DELETE, PW-
SKIP, STG-SKIP, SkipCond, CANCELLED, DELETED, and INACTIVE. These statuses are displayed in the
Backlog. Some ineligible statuses are displayed in History as well.
• Failure statuses
Failure statuses signify a task has failed. Failure statuses include DIED, ABORTED, KILLED, TIMEDOUT, and
LAUNCH ERROR. They may be displayed in the Backlog or History.
• Interim statuses
Interim statuses signify that a task has failed. Interim statuses include: DEAD, ABORTD, KILL, KILL1, KILLING,
TIMEOUT, LAUNCH ERR. They are displayed in the Backlog. Assuming that the Automation Engine is up and
running, these tasks will quickly move to History in a Failure status.
Satisfying Each Predecessor Link Type
The requirements for each type of predecessor link to be met are described below:
• Started
The predecessor starts or is skipped.
Started predecessors should never by defined along with other predecessors on the same Job. Doing so could
cause the task to stay in a PRED WAIT status even after all predecessor requirements are met.
• Success since last run
The predecessor runs and goes into an ineligible status or FINISHED status since the last time this Job
ran. This link type is only available for external predecessors. These predecessors are used when external
predecessors need to be evaluated:
• Across more than one virtual day.
• Multiple times within a virtual day.
For more information, see Understanding Success Since Last Run Predecessors.
• Success (default)
The predecessor runs and goes into an ineligible status, FINISHED status, or is removed from the Backlog.
For example, a task aborts and moves from the Backlog because it does not have the Stay in Queue on abort
setting selected, or the task is manually deleted from the Backlog.
The only difference between a Success and Success (skip on failure) predecessor is what happens when a task
fails.
• Success only when FINISHED
The predecessor runs and goes into a FINISHED status. This link type is only available for external
predecessors. If the external predecessor is deleted, it will not satisfy the predecessor link requirements.
• Success (skip on failure)
The predecessor runs and goes into an ineligible execution status or FINISHED status. This task is skipped
when the predecessor runs and goes into a failure status. Often used for branching logic.
If a task with a Success (skip on failure) predecessor meets Skip requirements, it will be skipped, even if it has
additional predecessors within an AND grouping.
• Failure
The predecessor runs and goes into a failure status.
• Failure (skip on success)
The predecessor runs and goes into a failure status. This task is skipped when the predecessor runs and goes
into an ineligible status or FINISHED status.
 Applications Manager 9.4.1

The only difference between a Failure and Failure (skip on success) predecessor is what happens when a task
fails. Often used for branching logic.
If a task with a Failure (skip on success) predecessor meets Skip requirements, it will be skipped, even if it has
additional predecessors within an AND grouping.
• Complete
The predecessor runs and goes into an ineligible status, a failure status, or a FINISHED status.
Predecessor links will not be satisfied while the predecessor is still in the Backlog and the predecessor's status
goes to an interim status. This is because interim statuses in the Backlog may be changed by conditions. Once
a FINISHED task moves to History, the predecessor link will be satisfied.
Even after a task's predecessor links are met, one or more conditions may also need to be met before the task
can run. Or perhaps a condition may take an action that changes the way a task runs. For more information on
conditions, see chapter Working with Conditions.
Selecting Link Types for External Predecessors to Process Flows
Complete, Success, Success only when FINISHED, and Success Since Last Run are the only link types you use
when creating a predecessor to a Process Flow. Success and Complete predecessors are both satisfied based on
the Process Flow's completion (when the Process Flow is no longer in an INITIATED status). In neither case does
Applications Manager take the status of the components in the referenced Process Flow into consideration.

Predecessor Requirement Table

The table below details when tasks' predecessors will cause them to wait in a PRED WAIT status, be skipped, or
be met. There is one specific case where a predecessor requirement can be met when the referenced task has not
started, been skipped, or been deleted.

When a predecessor link type is: And the referenced task: The task's predecessor will:

Started Hasn't started yet Cause the task to wait in a PRED

WAIT status.

Is skipped or deleted Be met.

Has started Be met.

Fails and stays in the Backlog Be met.

Fails and leaves the Backlog Be met.

Finishes successfully Be met.

Success Hasn't started yet Cause the task to wait in a PRED

WAIT status.

Is skipped or deleted Be met.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Cause the task to wait in a PRED
WAIT status.

Fails and leaves the Backlog Be met.

Finishes successfully Be met.

Success since last run Hasn't started yet Cause the task to wait in a PRED
WAIT status.
 Applications Manager 9.4.1

When a predecessor link type is: And the referenced task: The task's predecessor will:

Is skipped or deleted Be eligible to run assuming the task

was skipped or deleted since the last
run of the task with the predecessor.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Cause the task to wait in a PRED
WAIT status.

Fails and leaves the Backlog Be eligible to run assuming the task
failed and left the backlog since
the last run of the task with the
predecessor.

Finishes successfully Be eligible to run assuming the task

finished successfully since the last
run of the task with the predecessor.

Success only when FINISHED Hasn't started yet Cause the task to wait in a PRED
WAIT status.

Is skipped or deleted Cause the task to wait in a PRED

WAIT status.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Cause the task to wait in a PRED
WAIT status.

Fails and leaves the Backlog Cause the task to wait in a PRED
WAIT status.

Finishes successfully Be met.

Success (skip on failure) Hasn't started yet Cause the task to wait in a PRED
WAIT status.

Is skipped or deleted Be met.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Cause the task to be skipped.

Fails and leaves the Backlog Be met.

Finishes successfully Be met.

Failure Hasn't started yet Cause the task to wait in a PRED

WAIT status.

Is skipped or deleted Cause the task to wait in a PRED

WAIT status.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Be met.

 Applications Manager 9.4.1

When a predecessor link type is: And the referenced task: The task's predecessor will:

Fails and leaves the Backlog Cause the task to wait in a PRED
WAIT status.

Finishes successfully Cause the task to wait in a PRED

WAIT status. A Failure predecessor
is unusual in that the task with
the predecessor will remain in the
Backlog in a PRED WAIT status
if the referenced task succeeds.
It is unlikely that you would want
a task to run based on the failure
of another task without skipping
when that task succeeds. Therefore,
Failure (skip on success) is more
commonly used than Failure.

Failure (skip on success) Hasn't started yet Cause the task to wait in a PRED
WAIT status.

Is skipped or deleted Cause the task to be skipped.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Be met.

Fails and leaves the Backlog Cause the task to be skipped.

Finishes successfully Cause the task to be skipped.

Complete Hasn't started yet Cause the task to wait in a PRED

WAIT status.

Is skipped or deleted Be met.

Has started Cause the task to wait in a PRED

WAIT status.

Fails and stays in the Backlog Be met.

Fails and leaves the Backlog Be met.

Finishes successfully Be met.

Scheduled External Predecessor Exception

There is one specific case where a predecessor requirement can be met when the referenced task has not started,
been skipped, or been deleted. It is when all of the following are true:
• The predecessor is external.
• The referenced task has a schedule.
• The schedule for the referenced task does not include the current day.
For more information, see Satisfying External Predecessors on Insert to the Backlog.

Working with Internal Predecessors

Applications Manager relies on predecessor links to determine execution order. By default, when you add a
component to a Process Flow, it is added with an internal success predecessor link. After adding components to
a Process Flow, you may want to create additional links within the Process Flow. This is done by manually adding
internal predecessor links.
 Applications Manager 9.4.1

Adding Internal Predecessor Links in Process Flows

When you add a component to a Process Flow, Applications Manager automatically creates success predecessor
and successor links based on the components selected or the drop location of the added component. After adding
a component to a Process Flow, you may want to create additional links within the Process Flow, or to external
references. You add predecessor links for Process Flow components using the mouse. To add predecessor links to
larger Process Flows, you can use the Predecessor Definer window.
Tracing Predecessors and Successors
You can trace predecessor and successor links through a Process Flow using the Show Predecessors/Successors
commands. If a predecessor or successor link connects to a component that is not in view, you can jump to the
component by selecting the source component, right-clicking, and selecting Jump to predecessors/successors.
Testing Process Flow Predecessors Links with a Process Flow Simulation
You can test your predecessors to see how a Process Flow will execute by running a Process Flow simulation.

Adding Internal Predecessor Links in Process Flows

When you add a component to a Process Flow, Applications Manager automatically creates Success predecessor
and successor links based on the components selected or the drop location of the added component. After adding
a component to a Process Flow, you may want to create additional links within the Process Flow, or to external
references. This topic describes how to create additional internal links. For information on creating external links,
see Adding and Editing External Predecessor Links.
 Applications Manager 9.4.1

When you add a new internal predecessor link, it can change the position of the parent component. For example, if
you add the link to a component that has no other link, the component will be moved to a position below the target
component for the link. This is illustrated above.
Creating Links with the Mouse
To create links with the mouse:
1. Select the source component for the predecessor link.
Predecessors can originate from and/or be assigned to components in sub Process Flows.
KIKI: You can create internal predecessors between components in nested Process Flows, but they will not
export/import to another Applications Manager instance. To work around this, you can either manually recreate
the predecessors on the target instance, or define External predecessors in the nested Process Flow definitions.
2. Select the predecessor link type by clicking on the parent component and doing one of the following:
• Press Ctrl+S (to add a Success predecessor).
• Right-click and select the type of predecessor.
• Open the Predecessor menu and select the type of predecessor.
 Applications Manager 9.4.1

If you are creating a predecessor link to a Process Flow, you must select the Complete, Success, Success only
when FINISHED, or Success since last run type predecessor link. Success and Complete both mean that all of
the components in the Process Flow must finish with any status.
3. Move the mouse pointer to the target component.
As you move the mouse pointer, the link moves with the pointer.
4. Click on the target component.
Applications Manager draws the link.
If you want to cancel the add procedure, click on a blank spot in the Process Flow instead of a component or a
group.
Creating Links with the Predecessor Definer Window
If you are working with a large Process Flow, or you want to add more than one predecessor link at a time, you
can use the Predecessor Definer window. In the image below, the TEST_JOB component is selected in the From
Jobs box, and DAILY_REPORT is selected as the To Job box. When you click Create predecessors, Applications
Manager will draw predecessor links from the TEST_JOB component to the DAILY_REPORT component.

To display the Predecessor Definer window, click the Predecessor Definer icon in the menu bar.
To display only the component names in the To Jobs box, select the Use short name option. When not selected,
this column shows the names of all parent Process Flows for the component.
 Applications Manager 9.4.1

Tracing Predecessors and Successors in a Process Flow

If you want to trace predecessor or successor links through a Process Flow, you can use the Show Predecessors/
Successors commands. The commands are available by selecting a component in the Process Flow and right-
clicking as shown below.

The available commands are described below.

• Only externals: Displays only the predecessor links from the selected object to external references.
 Applications Manager 9.4.1

• Only predecessors: Displays only the predecessor links for the selected object. In this image, the predecessor
links are shown for INV_UPDATE.

• Only successors: Displays only the successor links for the selected object. In this image, the successor links
are shown for INV_UPDATE.
 Applications Manager 9.4.1

• Show All: Displays the predecessor and successor links for the selected object. In this image, the predecessor
and successor links are shown for INV_UPDATE.

Jumping to Predecessors and Successors

If a predecessor or successor link connects to a component that is not in view, you can jump to the component
by selecting the source component, right-clicking, and selecting Jump to predecessors/successors. For more
information, see Editing Predecessor Links.
 Applications Manager 9.4.1

Testing Process Flow Predecessor Links with a Process Flow Simulation

After you have created a Process Flow, you can check to see if the components will execute in the correct order by
running a Process Flow simulation. When you run a simulation, Applications Manager steps through the Process
Flow using the predecessor links. You can run a simulation in Fast or Slow mode. To enhance the simulation, you
can set individual components to fail during the simulation.

Procedure
To run a Process Flow simulation:
1. If you want a component to fail during the simulation, select the component, right-click, select Completion code
for simulation, and select Failure.
Applications Manager draws a red box around the component.
2. Open the Simulation menu and choose the speed for the simulation: Fast or Slow.
The simulation speed can be saved for your workstation by selecting Save Preferences from the File menu.
For more information, see Saving Preferences for Creating Predecessors.
3. To start the simulation, open the Simulation menu and choose Start.
Managing a Simulation
 Applications Manager 9.4.1

When Applications Manager runs a simulation, it highlights each component as it executes.

If the predecessor links to a failing component are success links, the simulation will stop at that point in the Process
Flow. For the simulation to continue, you must remove the fail code from the component. To remove the fail code:
1. Select the failing component and right-click.
2. Select Completion code for simulation, and select Reset completion code.
Applications Manager continues the simulation.

To: Open the Simulation menu and select:

End a simulation Stop
Stop a simulation Suspend
Continue a simulation Resume

Working with External Predecessors

You can also add predecessor links to Jobs, Process Flows, and Process Flow components outside the Process
Flow. These are called external predecessor links. You also create external predecessor links for a standalone Job
from the Jobs window and for non-running tasks in the Backlog. When you add external predecessor links to tasks
in the Backlog, the predecessors are only applied to that running of the task. They do not affect the Job or Process
Flow definition.
Satisfying External Predecessors on Insert to the Backlog
Applications Manager determines if external predecessor links are satisfied when their task is inserted into the
Backlog based on a set of rules described in Satisfying External Predecessors on Insert to the Backlog. If a task's
external predecessors are not satisfied on insert to the Backlog, the task will go to a PRED WAIT status until its
predecessor requirements are met.
Understanding the Virtual Workday
The virtual workday is a point in time each day that limits how far back Applications Manager will search in the
Backlog and History for a predecessor. A task's virtual day is determined by the original start time of that task, not
when the task runs.
Predecessors (other than Success since last run) are evaluated within the same virtual day. A predecessor link is
considered met when the predecessor task is not scheduled to be run in that virtual day as long as the predecessor
has a schedule associated with it. When tasks are staged, their start time is set to their scheduled start time.
Internal predecessors exist within the same Process Flow, and therefore are, by definition, within the same virtual
day. Thus the virtual workday start time is significant for external predecessors, but not internal predecessors.
Understanding Success Since Last Run Predecessors
Success since last run predecessors are only available for external predecessors. The requirements for Success
since last run predecessors are the same as success predecessors, except they do not adhere to the virtual
workday. Success since last run predecessors are used when external predecessors need to be evaluated:
• Across more than one virtual day.
• Multiple times within a virtual day.
Adding and Editing External Predecessor Links
An external predecessor link connects a Job, Process Flow, or Process Flow component to an external Job,
Process Flow, or Process Flow component. If you are working with Process Flows and there is a nested Process
Flow in the parent Process Flow, you can create an external predecessor link for the nested Process Flow, but not
for components within the nested Process Flow.
Deciding Between Predecessors and CHECK HISTORY Conditions
External predecessors and CHECK HISTORY conditions are very similar. However, they each offer unique
advantages. It is important to understand them both and use the one that is right for your needs.
Removing External Predecessors by Queue
To remove a Job or Process Flow header's external predecessors on insert to the Backlog, assign it to the
REMOVE_EXT_PREDS_ON_INSERT Queue. The REMOVE_EXT_PREDS_ON_INSERT Queue does not ship
with Applications Manager. If you wish to use it you can create it by hand or run an Applications Manager import
 Applications Manager 9.4.1

and select REMOVE_EXT_PREDS_ON_INSERT. The REMOVE_EXT_PREDS_ON_INSERT.exp file ships in the

import directory.

Satisfying External Predecessors on Insert to the Backlog

External predecessor links create dependencies to Jobs or Process Flows outside the parent Process Flow. They
are satisfied when their task is inserted into the Backlog based on the rules below. If a task's external predecessor
is not satisfied on insert to the Backlog, the task will go to a PRED WAIT status. For a list of predecessor execution
rules for tasks in a PRED WAIT status, see Understanding Predecessor Execution Rules.
Predecessor Task Status Terminology
Use the following predecessor status groups to help you understand predecessor link requirements.
The FINISHED status: A status of FINISHED may be displayed briefly in the Backlog when a task successfully
completes its operation. Assuming that the Automation Engine is up and running, FINISHED tasks in the Backlog
will quickly move to History.
Ineligible statuses: Ineligible statuses signify that a task is no longer eligible to run. Ineligible statuses include:
PW-DELETE, PW-SKIP, STG-SKIP, SkipCond, CANCELLED, DELETED, and INACTIVE. These statuses are
displayed in the Backlog. Some ineligible statuses are displayed in History as well.
Failure statuses: Failure statuses signify a task has failed. Failure statuses include DIED, ABORTED, KILLED,
TIMEDOUT, and LAUNCH ERROR. They may be displayed in the Backlog or History.
Interim statuses: Interim statuses signify that a task has failed. Interim statuses include: DEAD, ABORTD, KILL,
KILL1, KILLING, TIMEOUT, LAUNCH ERR. They are displayed in the Backlog. Assuming that the Automation
Engine is up and running, these tasks will quickly move to History in a Failure status.
Satisfying External Success Predecessors on Insert to the Backlog
External success predecessor requirements are satisfied when the Job or Process Flow is inserted into the Backlog
if any of the following are true:
• The predecessor's last run in the virtual day finished with an ineligible status.
• The predecessor's last run in the virtual day finished with a FINISHED status.
• The external predecessor has a schedule, but is not scheduled to run in the current virtual day and is not in the
Backlog.
External success predecessors will be considered not satisfied if they are in the Backlog with an interim status.
The image below shows a process diagram for determining whether external success predecessors are satisfied
on insert to the Backlog. Once a task goes into a PRED WAIT status, it will remain there until:
• The predecessor runs and goes into an ineligible execution status or FINISHED status.
• The predecessor is removed from the Backlog.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Satisfying External Failure Predecessors on Insert to the Backlog

External failure predecessor requirements are satisfied when the Job or Process Flow is inserted into the Backlog if
any of the following are true:
• The predecessor's last run in the virtual day was a failure status.
• The external predecessor has a schedule, but is not scheduled to run in the current virtual day and is not in the
Backlog.
External failure predecessors will be considered not satisfied if they are in the Backlog with an interim status.
The image below shows a process diagram for determining whether external failure predecessors are satisfied on
insert to the Backlog. Once a task goes into a PRED WAIT status, it will remain there until:
• The predecessor runs and goes into a failure status.
• The predecessor is removed from the Backlog.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Understanding the Virtual Workday

The virtual workday is a point in time each day that limits how far back Applications Manager will search in the
Backlog and History. You can reset the virtual workday start time by running the install script and selecting Setups.
When Applications Manager evaluates a predecessor, it looks back in time for the most recent execution of that Job
or Process Flow. The virtual workday start time is used to determine how far back in time Applications Manager will
look. For example, if you set the virtual workday for midnight each night, Applications Manager will check back only
to midnight. The current virtual workday start time is displayed to the left of the status bar on the Explorer window
as shown below.

Virtual Day for Tasks Determined by Their Original Start Time

A task's virtual day is determined by the original start time of that task or its parent Process Flow. The virtual day is
not affected by the following factors:
• When the task is inserted into the Backlog
• When the task runs
The start time for scheduled tasks is their scheduled start time, not their staged start time.
 Applications Manager 9.4.1

Internal Predecessors
Internal predecessors exist within the same Process Flow. Therefore, the start time for all components in the
Process Flow is always the same. For this reason:
• Success since last run and Success only when FINISHED link types are not available for internal predecessors.
• The virtual day never affects internal predecessors.
External Predecessors
Almost all external predecessors link types are subject to the virtual day. The only predecessor type that does not
take the virtual day into consideration is the Success since last run type. For more information on predecessor link
types, see Understanding Predecessor Execution Rules.
Setting the Virtual Workday Start Time
The virtual day start time is set when you install Applications Manager. To reset it to a different time, rerun the
install. For UNIX run the awinstall script. For Windows run setup.exe. The install script will show you the current
value for the virtual day and ask if it is correct. You can enter 'No' and update it.

Understanding Success Since Last Run Predecessors

Success since last run predecessors are only available for external predecessors. The requirements for Success
since last run predecessors are the same as success predecessors, except they do not adhere to the virtual
workday. Success since last run predecessors are used when external predecessors need to be evaluated:
• Across more than one virtual day.
• Multiple times within a virtual day.
Examples for each are described below.
In order to satisfy an Success since last run predecessor link, a predecessor task must exist in History.
Satisfying Predecessors Across Virtual Workdays
Suppose you have a nightly batch window that starts each night at midnight. The exception to your batch cycle is a
particular task that runs prior to the start of the virtual workday. There may be another task that needs to reference
that task. Success predecessor requirements will not be met if the predecessor task ran before the start of the
current virtual day.
For example, task B has a Success since last run predecessor link to task A. The diagram on the left in the diagram
below shows that the predecessor requirements for task B are satisfied even though task A runs and finishes prior
to the start of the current virtual day. Therefore task B runs.
When task B has a Success predecessor link to task A, task B's predecessor requirements are not met. The
diagram below on the right shows that the predecessor requirements for task B are not satisfied when task A runs
before the virtual day. In that case, task B stays in a PRED WAIT status.
 Applications Manager 9.4.1

The Success predecessor requirement for task B shown on the right would be satisfied on insert if task A includes
a schedule, but is not scheduled to run today.
Requiring Predecessor Requirements to be Satisfied Each Time in a Virtual Workday
There may be some tasks you wish to run several times in a virtual day. Each time they run, you want their
predecessor requirements to be re-evaluated. The diagram below shows that the predecessor's requirements
for the second run of task B are not met with a Success since last run predecessor. This is because task A did
not run again since the last time task B ran. With a Success predecessor from task B to task A, the predecessor
requirements for every instance of B in the current virtual day will be satisfied as soon as task A runs the first time.
 Applications Manager 9.4.1

Adding and Editing External Predecessor Links

An external predecessor link connects a Job, Process Flow, or Process Flow component to an external Job,
Process Flow, or Process Flow component. If you are working with Process Flows and there is a nested Process
Flow in the parent Process Flow, you can create an external predecessor link for the nested Process Flow, but not
for components within the nested Process Flow. In the image below, you could create an external predecessor link
for the SIMPLE Process Flow, but not any of the components within the Process Flow.
 Applications Manager 9.4.1

Example Use
External predecessor links can be useful in many situations, including the following: Two application groups in a
company have created their own nightly processing Process Flows. Each group's Process Flow depends on the
successful execution of Jobs within the other group's Process Flow. To keep the Process Flows in sync, they create
external predecessor links to the components in each others' Process Flows.
Procedure
To add an external predecessor link:
1. Open the Jobs/Process Flows window.
2. Select a Job, Process Flow, or one or more components (Shift+Click, Ctrl+Click) and do one of the following:
 Applications Manager 9.4.1

• Select the External option in the components group box

• Drag the components into the External Predecessors box.
Applications Manager adds the components to the External Predecessors box.
The predecessor requirement can only be satisfied for the referenced Job, Process Flow, or Process Flow
component. When you add a predecessor link to a Process Flow component, it is based on that component's
lineage. Therefore, a predecessor to TEST_JOB in the SAMPLE_PROCESS_FLOW will not be resolved by:
• TEST_JOB when it is run in a different Process Flow than SAMPLE_PROCESS_FLOW.
• TEST_JOB when it is run by itself outside of the SAMPLE_PROCESS_FLOW.
• TEST_JOB when it is run in the SAMPLE_PROCESS_FLOW and the SAMPLE _PROCESS_FLOW is
nested in SUPER_PROCESS_FLOW.
3. Select the parent component and choose the predecessor link type by doing one of the following:
• Open the Predecessor menu and select the type of predecessor.
• Right-click and select the type of predecessor.
• Press Ctrl+S (to add a Success predecessor).
If you are creating a predecessor link to a Process Flow, you must select the Complete, Success, Success only
when FINISHED or Success since last run type predecessor link. Success and Complete both mean that all of
the components in the Process Flow must finish with any status.
4. Click on the predecessor component in the External Predecessors window.
Applications Manager draws the predecessor link between the two components.
Virtual Workday
Unless the Success since last run predecessor type is selected, external predecessor links are subject to the
constraints of the Applications Manager virtual workday. The virtual workday is a point in time each day that limits
how far back Applications Manager will search in the Backlog and History. For information on the virtual workday,
see Understanding the Virtual Workday.

Deciding Between Predecessors and CHECK HISTORY Conditions

Conditions control task execution in various ways. One particular type of condition, a CHECK HISTORY condition,
can be used similarly to a predecessor. For more information on conditions, see chapter Working with Conditions.
Both predecessors and conditions can be added to Jobs, Process Flows, or Process Flow components. They are
both used to control the execution of the Job/Process Flow they are assigned to. When Jobs/Process Flows are
submitted to the Backlog, Applications Manager evaluates whether any predecessors or conditions cause them not
to start.
With predecessors, you can run the Job or Process Flow only when its predecessor requirements are met. If the
predecessor requirements are not met, the task will wait in the Backlog with a task status of PRED WAIT.
With a CHECK HISTORY condition, you can check History to see if a Job or Process Flow has succeeded or failed
within a set time period. If the Job/Process Flow has not run, the task will wait in the Backlog with a task status
CONDITN WAIT. A CHECK HISTORY condition is shown below.
 Applications Manager 9.4.1

Although the two are very similar, each option offers its own unique advantages.
Advantages of Predecessors
Predecessors have several distinct advantages. They:
• Are managed from memory. They use fewer system resources than conditions which run a SQL statement
every time they are evaluated.
• Check for the Job/Process Flow since the last virtual workday start time.
For more information on the virtual day, see Understanding the Virtual Workday.
• Can be evaluated based on some predecessor types that CHECK HISTORY conditions cannot. For a list of
predecessor types, see Understanding Predecessor Execution Rules.
Advantages of CHECK HISTORY Conditions
CHECK HISTORY conditions have several distinct advantages. They:
• Allow you to specify a particular number of days, hours, or minutes to check for.
For an example of a condition that checks for a Job in a set time period, see Checking for a Finished Task in
History.
• Can be assigned to different timings (before a task runs, during its execution, after it has run, or when it is
deleted).
• Can be assigned different actions (cancel a Process Flow, request a Job, set a Substitution Variables, etc.).
Recommendation
Generally, you should use predecessors when possible. If you are not able to satisfy your task execution
requirements with predecessors, then turn to CHECK HISTORY and other conditions.
 Applications Manager 9.4.1

Editing Predecessor Links

You edit predecessor links from the Components tab for Process Flows and Process Flow components or the
Predecessors tab for stand-alone Jobs.
Changing Link Types
To change a link type, select the existing link from the flow diagram or from the Predecessor Editor pane. Right-
click, choose Change predecessor type to from the pop-up menu, and select a predecessor link type.

Deleting Predecessor Links

To delete a predecessor link, select the predecessor and do one of the following:
• Right-click and select Delete.
• Press Delete.
• Open the Edit menu and select Delete.
If this is the only predecessor on the component, the component and its successors will be moved to the upper
right corner of the parent Process Flow box
 Applications Manager 9.4.1

A message window is displayed informing you of this move and giving you the chance to cancel the action. The
message box includes a checkbox that prevents the message box from being displayed again during the current
session.
Redirecting Internal Predecessor Links
You can redirect a predecessor link to another component within the Process Flow. To redirect a link, select the link
and drag the predecessor end of the link to the new target component.
Jumping to Predecessors and Successors
If a predecessor or successor link connects to a component that is not in view, you can jump to the component by
selecting the source component, right-clicking, and selecting Jump to predecessors/successors. Applications
Manager opens the Jump to dialog window. You can jump to predecessors or successors and return to the initial
component by selecting the Go back to originator button.

Using the Predecessor Editor Box

Use the Predecessor Editor box to view the predecessor links for Jobs, Process Flows, Process Flow
components and non-running tasks in the Backlog.

To change AND/OR logic for: Go to:

Process Flows and Process Flow components Components tab on the Process Flows window as
shown in the image below.

Jobs Predecessors tab on the Jobs window.

Non-running tasks in the Backlog Predecessors tab on the Task Details window.
 Applications Manager 9.4.1

If a component has more than one predecessor, you can apply AND/OR logic to the predecessor links. If you link
two or more predecessors with AND logic, all the predecessors must be satisfied before the component can run. If
you link the predecessors with OR logic, only one predecessor's requirements must be satisfied for the component
to run. You can also mix AND and OR logic for a component's predecessors.
Using the Predecessor Editor Box
Following are guidelines for using the Predecessor Editor box:
• All listings below a blue OR or red AND icon fall within that logical structure. In the image above, a blue OR
is the top level icon, below it are two pairs of tasks, each under a nested AND. This means that JOB_E in
PROCESS_FLOW_1 will be eligible to run if both tasks in either pair are successful.
• Predecessor links in the window are listed with the parent Process Flow name followed by component name.
• You can change AND headings to OR headings and vice versa by right-clicking the heading and selecting the
Change to command.
• You can create new AND and OR headings under existing headings by selecting the heading, right-clicking, and
selecting the appropriate Create nested command.
• You can drag a predecessor link from one heading to another.
• You can drag AND/OR headings to other headings.
 Applications Manager 9.4.1

Changing the AND/OR Logic

Topic Changing the AND/OR Logic provides details of how to create AND/OR predecessor logic.

Changing the AND/OR Logic

You can change the AND/OR logic of predecessor links for Jobs, Process Flows, Process Flow components and
non-running tasks in the Backlog. For example, you could create the following links:
• Job A is successful and Job B is successful
or
Job C is successful and Job D is unsuccessful
AND and OR logic can be nested to three levels. To change the predecessor logic, you use the Predecessor
Editor box in the right pane shown below.

Changing the AND/OR Logic

You can change the AND/OR logic by manipulating the predecessor links in the Predecessor Editor box.
 Applications Manager 9.4.1

Action Steps

Change a predecessor link from AND to OR 1. Select the predecessor link and right-click.
2. Select Change to Or.
Applications Manager adds an OR heading with the
predecessor link indented under the heading.

Move a predecessor link from one AND/OR group to Click on the predecessor link in the Predecessor
another Editor box and drag it to the target AND or OR group
heading.

Delete a predecessor link Select the predecessor link in the Predecessor Editor
box, right-click, and select Delete.

Add a new Or group Select an AND group, right-click, and select Change to
Or.

Creating Nested AND/OR Logic

You can create new AND and OR headings under existing headings by selecting the heading, right-clicking, and
selecting the appropriate Create nested command.
Example
In this example, a set of three AND predecessors is changed to AND/OR logic, then changed back. The example
below shows a task with three predecessors. In the example on the left, all three Jobs must complete successfully
to satisfy the predecessor requirements. In the example on the right, either JOB_A or both JOB_B and JOB_C
must complete successfully to satisfy the predecessor requirements.

To make the change shown above:

1. Create a nested AND by selecting the AND heading, right-clicking, selecting Create nested, and selecting And.
2. Change the top-level AND heading to OR by selecting the AND heading, right-clicking, and selecting Change to
Or.
3. Select the predecessor statements and drag them to the appropriate AND headings.
To revert to the original arrangement with all AND predecessors:
1. Drag the three predecessor statements to the OR heading.
2. Change the OR heading to AND by selecting the OR, right-clicking, and selecting Change to And.
Rules for Skip on Failure and Skip on Success
If a Job with a Success (skip on failure) or Failure (skip on success) predecessor meets Skip requirements, it will
be skipped, even if it has additional predecessors within an AND grouping.
 Applications Manager 9.4.1

Saving Preferences for Creating Predecessors

There are several options you can select when working with predecessors. By selecting Save Preferences
from the File menu, you can save your preferences. Saved preferences apply to, and can be saved from, the
Components tab for Process Flows, the Predecessors tab for Jobs, and the Flow Diagram tab for task details in
the Backlog and History. Saved settings apply only to your workstation. All predecessor preferences are described
below.
Fitting Process Flows to Size
You decide whether you want to scale objects. This is done by selecting the Fit to size option from the View menu.
For more information, see Sizing and Aligning the Process Flow Display. This option is not selected by default.
Showing Process Flows Vertically or Horizontally
You decide whether Process Flows are displayed horizontally or vertically. This is done by selecting the Show
Horizontal/Show Vertical flip-flop command from the View menu. For more information, see Sizing and Aligning
the Process Flow Display. Process Flows are displayed vertically by default.
Drawing Squared Arrows
You decide whether Applications Manager uses right angles to draw predecessor links between components that
are in adjacent levels. This is done by selecting the Draw squared arrows option from the View menu. For more
information, see Customizing Predecessor Link Displays. This option is selected by default.
Showing Arrows as Successors
You decide whether Applications Manager points the arrow heads towards predecessors or successors. This is
done by selecting Show arrows as successors from the View menu. For more information, see Customizing
Predecessor Link Displays. This option is not selected by default.
Prompting for Alias Names
In Applications Manager, you can add multiple copies of the same Job or Process Flow to a Process Flow.
However, each component you add must have a unique alias name. The Prompt for alias name option
determines if the Prompt for alias name window is displayed when you select a component from the Jobs/
Components window and drag it into a Process Flow. This is done by making a choice on the Prompt for alias
name option of the Options menu.
For more information, see Controlling Process Flow Display Options. The default setting is Only for duplicates.
Drawing Shaded Backgrounds
You decide whether Applications Manager cycles through three shades to set apart nested Process Flows. This is
done by selecting Shaded background from the Options menu. For more information, see Controlling Process
Flow Display Options. This option is not selected by default.
Showing Predecessor Types
You can select the predecessor types that are displayed. This is done by selecting predecessor types from the
Show Predecessors option on the Options menu. Predecessor types include:
• Show Started Predecessors
• Show Success Predecessors
• Show Failure Predecessors
• Show Success (Skip On Failure) Predecessors
• Show Failure (Skip On Success) Predecessors
• Show Complete Predecessors
For more information, see Controlling Process Flow Display Options. These options are all selected by default.
Showing Pop-Up Tables
You can decide whether to enable or disable the pop-up tables on the Predecessors tab of the Task Details
window by unchecking the Show status info option under the Options menu. This preference is set on the Task
Details window, and only affects the Task Details window. Pop-up tables are shown by default.
Simulation Speeds
You decide the speed of the Process Flow simulations. This is done by selecting Fast simulation or Slow
simulation from the Simulation menu. For more information, see Testing Process Flow Predecessor Links with a
Process Flow Simulation. The default setting is Fast simulation.
 Applications Manager 9.4.1

Using Predecessor Links to Accomplish Specialized Tasks

You can accomplish specialized tasks by using different predecessor link types and combining predecessor
functionality with other features of Applications Manager.
The success predecessor link is the default and easiest predecessor to understand. It is acceptable in the
majority of cases. However, there may be times when you want to do something more complex where another
predecessor link type is required, or you may need to combine predecessor link functionality with the other features
of Applications Manager. When working with predecessor links, it is important that you understand the information
in Understanding Predecessor Execution Rules. Additionally, if you are creating external predecessor links, it is
equally important to understand Adding and Editing External Predecessor Links.
Without an understanding of these topics, the Process Flows you build may not run the way you expect. For
example, you may be surprised that a task with a Success predecessor link runs, if the predecessor task aborts
and goes to History as the result of a condition.

Evaluating Predecessors on Select Days

There may be some tasks whose predecessors you only want to evaluate on certain days of the week. For
example, Job A runs Monday through Friday. You want Job A to run after Job B completes successfully on Monday,
Wednesday, and Friday. On Tuesday and Thursday, however, Job A can run without regard to Job B.

To allow the Job to always run on select days, define predecessor requirements that are always met on those days.
To do this, create additional predecessors using OR logic to special dummy Jobs that run each day.
 Applications Manager 9.4.1

In the image above, Job A will run if the TUESDAY, THURSDAY, or B Jobs complete successfully. The TUESDAY
Job is scheduled to run at the start of Tuesday's virtual day, and the THURSDAY Job is scheduled to run at
the start of Thursday's virtual day. Therefore, Job A runs on Monday, Wednesday, and Friday only after Job B
completes (assuming Job A is scheduled to run Monday through Friday), and it runs on Tuesday and Thursday
because the TUESDAY and THURSDAY Jobs run.
Procedure
To only evaluate a predecessor on select days:
1. Create a dummy Job for each day you do not wish to evaluate a predecessor.
A dummy Job is a Job that runs, but doesn't execute a meaningful program or script. An easy way to create
dummy Jobs is to copy the TEST_JOB that ships with Applications Manager. You can name the dummy Jobs
after the days of the week. For information on copying Jobs, see Copying Applications Manager Objects.
2. Add schedules to each dummy Jobs so they run immediately after the start of the virtual day.
For information on scheduling Jobs and Process Flows, see chapter Scheduling Jobs and Process Flows.
3. Add external predecessor links to the dummy Jobs.
4. Set the predecessor logic to OR for all predecessors.
For information on setting OR logic, see Using the Predecessor Editor Box.

Running Recovery Tasks Using Failure (Skip On Success) Predecessors

You can use a Failure (skip on success) predecessor link type as shown below to run recovery tasks when a
component in a Process Flow fails.

The DATA_PROCESSING Process Flow shown below runs five components. First the DATA_LOAD Job runs.
Next, the MAJOR_UPDATE and SMALL_UPDATE Jobs run. Once the MAJOR_UPDATE Job finishes, the
REPORTING_01 and REPORTING_02 Jobs run.
 Applications Manager 9.4.1

If the MAJOR_UPDATE Job aborts, several recovery scripts must run to restore the database. You can create Jobs
that run the recovery scripts and add the Jobs to the Process Flow.
Using Failure (skip on success) predecessors, you can automate the recovery Jobs to only execute when the
MAJOR_UPDATE Job completes with a status of ABORTED, DIED, or TIMEDOUT. In the first image above, the
CLEAR_PARTIAL_TRANSACTIONS, REINITIALIZE_COUNTERS, and RESTAURANTS components include
Failure (skip on success) predecessor links to MAJOR_UPDATE. They only run when MAJOR_UPDATE fails. If
MAJOR_UPDATE goes to History with a FINISHED status, they are skipped.
Notice that CLEAR_PARTIAL_TRANSACTIONS, REINITIALIZE_COUNTERS, and RESTAURANTS are included
in a group. This is done based on organizational preference. They just as easily could have been members of a
nested Process Flow. If they were members of a nested Process Flow, you would use a single Failure (skip on
success) predecessor from the Process Flow to the MAJOR_UPDATE component. You cannot add predecessor
links to components in a nested Process Flow.

Using Branching Logic to Determine Which Job Runs

There may be times when you want the successful or unsuccessful completion of a Job to determine which of two
other Jobs will run. For example, if JOB_A completes successfully, you want only JOB_B to run. However, if JOB_A
fails, you want only JOB_C to run. The logic is illustrated below.
 Applications Manager 9.4.1

This can be achieved by creating a Process Flow which includes JOB_A, JOB_B, and JOB_C. JOB_B would
include the predecessor link Success (skip on failure). JOB_C would include the predecessor link Failure (skip on
success). A sample Process Flow below named BRANCH shows this.
 Applications Manager 9.4.1

How the BRANCH Process Flow Runs

When the BRANCH Process Flow runs and JOB_A finishes successfully, JOB_B runs and JOB_C is skipped.
When the BRANCH Process Flow runs and JOB_A aborts, JOB_C runs and JOB_B is skipped. JOB_A remains
in the Backlog in an ABORTED status, and the BRANCH Process Flow remains in the Backlog in an INITIATED
status. This allows for operator intervention.
Sending JOB_A to History when it Aborts
If JOB_A fails and you do not want it to remain in the Backlog, you can add a 'dummy' Job with a condition to
remove it.
 Applications Manager 9.4.1

In the image above, JOB_D includes predecessor links to run after JOB_B or JOB_C. JOB_D also includes a
condition which cancels the remaining components in the Process Flow after it runs. Now when JOB_A aborts the
following happens:
• JOB_A remains in the Backlog in an ABORTED status.
• JOB_B is skipped.
• JOB_C runs.
• JOB_D runs. When JOB_D finishes, its condition is executed. This cancels JOB_A and sends the BRANCH
Process Flow to History.
It is important that the dummy Job is the last Job in the Process Flow, because it would also cancel any additional
components which have not yet run.
 Applications Manager 9.4.1

You would want to make sure the Stay in Queue on abort option was set for JOB_A. Otherwise, both JOB_B and
JOB_C would run when JOB_A aborted.

Linking an External Predecessor in a Nested Process Flow Component

To link an external predecessor in a nested Process Flow's component, you must add the external predecessor
to the nested Process Flow's definition. When you do this, the link will be displayed in the parent Process Flow's
definition.
You may want to include an external reference from one Process Flow's component to another Process Flow's
component and include both Process Flows in a parent Process Flow. Consider the following scenario:
• There are two Process Flows: NEST_A and NEST_B.
• NEST_A includes three Jobs as Process Flow components: X, Y, and Z.
• NEST_B includes three Jobs as Process Flow components: P, Q, and R.
• NEST_A and NEST_B run with their own schedules and also as nested components in a third Process Flow
named PARENT.
• Component Y in the NEST_A Process Flow includes an external predecessor to component P in the NEST_B
process flow.
• The predecessor relationship between Y and P must also exist when the PARENT Process Flow is run.
The image below shows the PARENT Process Flow with a predecessor relationship between Y and P as explained
above.

Building the Process Flows

To set this up you would:
1. Create the NEST_A, NEST_B, and PARENT Process Flows.
2. From the definition of predecessors to NEST_A, create predecessors from Y to P in both NEST_B and
PARENT/NEST_B with OR logic as shown below.
Y will run in either NEST_A or PARENT/NEST_A if P runs in either NEST_B or PARENT/NEST_B.
The predecessor link will be displayed in both the PARENT and PROCESS_FLOW_A Process Flow definitions.
 Applications Manager 9.4.1

Adding Prompts to Jobs and Process Flows

The program or script you create a Job for may accept parameters. You pass parameters to a program or script
in Applications Manager using prompts. Before creating prompts for your Jobs, it's a good idea to think about how
best to take advantage of all the features they provide.
 Applications Manager 9.4.1

To best determine the prompts you will create for your Applications Manager Jobs, you should start by thinking
about the parameters that each program or script requires and where they come from. Parameters that a program
or script may require include:
• Selectable options in an application
• Options an application requires that never change, for example the name of a printer
• The number of records in a database table
• Values in a database that may continually change, such as account balances
• A list of items in a database, such as customer names
• A list of items which are not in a database, such as values in a daily run book
• Entirely open-ended user-defined parameters
• Dates and times
Planning Your Prompts
Before creating prompts for your Jobs, it's a good idea to think about how best to take advantage of all the features
they provide. Topic Deciding which Prompts to Use includes some of the key concepts you should take into
consideration to take full advantage of the powerful features Applications Manager prompts provide you.
Prompts Defined by Data Types
When you create a prompt, you assign it a data type. The data type defines the format of the data that will be used
in the prompt. There are several basic Data Types: Character, Date, Number, Multi (for combining two Data Types),
List (for selecting options from a list without using a SQL statement), and File (for selecting a file from a directory).
Character data type can incorporate a SQL statement that searches the database and returns a set of values that
can be selected for a prompt. For information on defining Data Types, see Defining Data Types.
Working Smarter by Copying Prompts
If you have defined prompts for a Job or Process Flow, you can use them in another Job or Process Flow using the
Copy button.
Passing Values Through a Process Flow
You also can create prompts for Process Flows to define values that will be used by the components added to the
Process Flows. You can pass prompts from a Process Flow to one or more component in the Process Flow using
numeric Substitution Variables. The values can be used in prompts, conditions, and aliases. The user can enter
values in one place and have them automatically used in one, several, or all of the components in a Process Flow.
This technique is described in Passing Values Through a Process Flow with Numeric Subvars.

Deciding which Prompts to Use

To determine how you should define a prompt in Applications Manager, start by thinking about whether the prompt
values are dynamic or static. Here are the definitions of those terms:
• Dynamic prompt values: A dynamic prompt value is a value that is automatically set each time the task is run.
It has the potential to be different each time the prompt is evaluated. Sample dynamic prompt values include the
number of sales orders in a database, a timestamp, and the date of the last day of the month. To automatically
set the value, Applications Manager uses a SQL statement to retrieve the value from a database.
• Static prompt values: When prompt values do not change, except when updated manually or with a condition
action, they are static. Sample static prompt values include company names, department names, and yes/no
flags.
If you are new to Applications Manager, you're probably only used to providing static values for parameters. But
you will find that dynamic values allow you to automate tasks that previously had to be run manually.
 Applications Manager 9.4.1

Using Dynamic Prompt Values

In Applications Manager, you define dynamic prompt values with Substitution Variables (Subvars) that include a
SQL statement. The statement retrieves a value from a database. Subvars including a SQL statement are called
dynamic Subvars. Several dynamic Subvars ship with Applications Manager. You can also create your own.
Dynamic Subvars are a cornerstone of automation and should be used whenever possible. Advantages of dynamic
Subvars include the following:
• Dynamic Subvars can be evaluated in scheduled Jobs and Process Flows. For example, you may have a Job
that always requires the current date. With a dynamic Subvar, an operator does not need to enter a date each
time a Job runs because it is done automatically.
 Applications Manager 9.4.1

• Dynamic Subvars can be used as default prompt values for Job and Process Flow prompts that will be
requested on an ad hoc basis. Consider this simple example: A user needs to supply the current date every time
they run a particular Job. With a dynamic Subvar, the date is filled in automatically when they request the Job,
saving time and eliminating the potential for error.
• Once defined, dynamic Subvars can be used in other parts of the Applications Manager product, including
Notifications, Output Scans, and conditions.
Other options, such as whether a prompt value is editable when requested, are determined by the prompt's details.
Using Static Prompt Values
When a prompt value is static, you should think about the best way to set the value. If it would be advantageous
for a developer creating the prompt, or the operator requesting a Job, to select a parameter value from a list, you
can create a prompt where users can select one or multiple prompt values from a list. Selecting values from lists
eliminates data entry errors. Usually you build lists for prompts with a SQL statement that pulls values from a
database table. Alternatively, you can build a list from the Applications Manager GUI, or specify a directory and
allow users to select file names as values. The way the list is built is determined by the prompt's data type.
If the value will not be included in a list, you can do either of the following, depending on your preference:
• Key in text as prompt values.
• Enter static Subvars. Values for static Subvars are stored in a database and retrieved at the time a Job is
requested. An advantage of using static Subvars for static prompt values instead of keyed-in values is that
changes can be made to the Subvar definition to update the value in all objects using the Subvar. Static Subvar
values can also be set by Applications Manager conditions.
Other options, such as whether a prompt value is required, editable, or has a default value are determined by the
prompt's details.

Prompt Formats for Ad Hoc Jobs and Process Flows

You can define prompts so that users can select values from lists when they request them on an ad hoc basis.
The values available and format of the prompt's data come from the data type you assign to the prompt and the
prompt's definition.
Some prompts allow users to select either one or multiple values from a list of values on the Submit window. The
values available and format of the prompt's data come from the data type you assign to the prompt. When you pick
a data type that allows you to select values from a list, you determine whether users can select a single value for
the prompt or multiple values.
 Applications Manager 9.4.1

An example Job with six common types of prompts is shown above. The first prompt is a simple fill-in prompt. The
next five show the available formats for prompts users can select values for. With them you can select:
• A single value from a list of radio buttons.
• A single value from a list of values window by clicking a Select button or alternately by keying in text.
• A single value from a list of values window by clicking a Select button or alternately by selecting from a drop-
down list.
• Multiple values from checkboxes.
• Multiple values from a multiple selection window by clicking a Select button.
The image below shows the Prompts tab of the Jobs window for the requested EMPLOYEES Job.
 Applications Manager 9.4.1

Example: Selecting a Single Value with a Radio Button

This example shows the prompt definition and data type for a sample prompt where users are able to select a
single value for a region from a list using radio buttons.
When you are ready to start defining Data Types and prompts, you can read the detailed descriptions included later
in this chapter. The example presented here helps give you context before you begin by showing the data type and
prompt definition.
Applications Manager 9.4.1
 Applications Manager 9.4.1

The prompt details from the Job's definition and its data type definition are shown above. Notice the following
settings that define the way the prompt will validate the data it passes to a program or script and how it will look:
• The Region data type includes a list of values. In its Type field, List is selected and the values are shown on the
List tab at the bottom of the window. You build a list of values with a List data type when you want to present
users with a list of options that are not already stored in a database.
• In the prompt definition, the Region data type is selected. Since Region has a List data type, the List of values
and Multi select radio buttons are active in the prompt definition. List of values is selected. Now when a user
submits this Job they will be able to select one of the values from the Region data type's list.
• On the Submit window shown below, there are six radio buttons, one for each of the five regions and one for
None. When None is selected, no value will be passed for this prompt. The None radio button exists because
the prompt doesn't require a value since the Value required box is not checked in the prompt definition.
 Applications Manager 9.4.1

Additional Examples
For additional example prompts, see the PROMPT_EXAMPLE Job that ships with Applications Manager.

Adding, Updating, and Deleting Prompts

You can add one or more prompts to Jobs and Process Flows.

Adding Prompts to a Job or Process Flow

To add a prompt to a Job or Process Flow:
1. Select the Prompts tab for a Job or Process Flow as shown above, and click the New button.
2. Complete the fields in the Edit Prompt window using the information below.
• Description
Text displayed in the Submit window when the Job/Process Flow is requested and on the Components tab
if the Job (or Process Flow) is added to a Process Flow.
• Variable name
 Applications Manager 9.4.1

The variable name for the prompt. For example, if you want to ensure that the prompt is assigned to the
variable 'time' (used in a SQL script, say), put 'time' in the Variable Name field. Variable names are used
differently by different Program Types (up to 100 characters).
• Default value
The default value for the prompt. When prompt values are selected from a list, you can pick them by clicking
the Select button.
If Allow changes is checked, the user can enter their own value for this prompt when it is requested. If your
prompt values include spaces or special characters, such as & or %, enclose those values in double quotes.
For information on when Subvars and Replacement Values are evaluated in Job and Process Flow
component prompts, see Using Subvars and Replacement Values in Job and Component Prompts.
For information on when Subvars set in Process Flow prompts are evaluated, see Passing Values Through a
Process Flow with Numeric Subvars.
You can include Environment Variables in prompt values. The Environment Variables must be enclosed in { }
curly brackets. When an Environment Variable is used in a prompt's value, its corresponding Environment
Variable object must be assigned to the Job via its Agent, Application, Program Type, or Job definition. For
more information on environmental variables, see topic Defining Environment Variables.
• Minimum/Maximum
Sets the minimum and maximum value a user can enter in response to the prompt. If the data type selected
includes a SQL statement you can select values using the Select buttons. If a Min value and Max value have
been defined for the data type, they will be displayed in these fields. For more information on these fields,
see Setting Minimum and Maximum Values for Prompts.
Only applies to the Submit window, not to Process Flow component prompts, the awrun process, or the API
calls.
• Max length
Sets the maximum number of characters a user can enter in response to the prompt (up to 512).
Only applies to the Submit window, not to Process Flow component prompts, the awrun process, or the API
calls.
Max length is not enforced when Subvars are used in the Default value field.
• Value required
When selected, the prompt must have either a default or user-entered value when the Job/Process Flow is
executed.
Only applies to the Submit window, not to Process Flow component prompts, the awrun process, or the API
calls.
• Allow changes
When selected, the User can enter a value for the prompt. If you do not select this option, the User cannot
change the default value.
Only applies to the Submit window, not to Process Flow component prompts, the awrun process, or the API
calls.
• Upper case
When selected, text entered for the prompt will be forced to upper case at the time the Job is submitted. The
default setting is determined by the prompt's data type.
Only applies to the Submit window, not to Process Flow component prompts, the awrun process, or the API
calls.
• Quote char
The quote character is required for some Program Types if null values or space characters are allowed in the
prompt. The quote character is placed before and after the value entered for the prompt. Single and double
quote characters are common choices.
• ToolTip
Additional information you enter about the prompt. When a user mouses over this prompt on the Submit
window, text from this field will be displayed in a ToolTip.
• From Data Type
 Applications Manager 9.4.1

When you select a data type with ToolTips, they are automatically entered in the ToolTip box and this non-
editable checkbox will be checked. If you edit the text in the ToolTip box, this checkbox will uncheck.
3. To save the settings and add the prompt to the Job or Process Flow, click OK.
Applications Manager adds the prompt to the list at the top of the Prompts tab.
4. To reorder the prompts in a Job or Process Flow, use the arrow buttons to the right of the list of prompts.
Updating and Deleting Prompts
To update or delete a prompt, select the prompt and click Edit or Delete.

Setting Minimum and Maximum Values for Prompts

The Minimum and Maximum fields specify a range of values that users can enter in response to a prompt. If
while defining a prompt, you select a data type with a Min value and Max value defined, those values automatically
populate the prompt's Minimum and Maximum fields as shown below.
The minimum value for date is 01-Jan-64 and the maximum value for date is 31-Dec-50. It will auto-populate when
configuring a job's Prompt for the Date data type.

The values serve as guidelines and can be changed. You can edit them by:
• Typing in new values.
• Entering Substitution Variables.
• Selecting from a list of values if the Select button is active. The Select button is active only when the data type
selected is a List data type or includes a SQL statement.

Defining Data Types

If the program run by a Job accepts parameters, you can create a prompt for each parameter in the program. When
you create prompts and Substitution Variables, you define its characteristics. You create Data Types for the express
purpose of defining prompts and Substitution Variables. Applications Manager ships with a number of predefined
Data Types. However, you will probably want to create your own Data Types to meet the needs of your operation.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Data Types. If you do not have access to them, see your
Applications Manager administrator.
Procedure
To define a data type:
1. From the Data Types Selector window, click New.
Applications Manager opens the Data Types window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Complete the fields using the information below.
• Name
A 100-character description for the data type.
• Type
General type-can be Character, Date, File, Number, Multi, List, or Password.
For example, a "Divisions" data type would use character, a "Product Count" data type would use number.
Multi, List, File, and Password Data Types are described in the subtopics that follow.
 Applications Manager 9.4.1

• Display Type
Defines how prompts using this data type will be displayed on the Submit window. There are three options:
• Text Field: A box in which the requestor may enter text.
• List Box: A box including a down-arrow. When a requestor clicks on the down-arrow, a list of values
appears. With List Boxes containing a list of values, text will auto-fill as the requestor types, based on the
available values for the prompt.
• Radio Buttons: Small circles that, when selected, have a smaller, filled-in circle inside them.
When a data type is used as a multi select prompt that has List Box or Radio Buttons selected, and there are
few enough choices to fit on the Submit window, the values will be displayed with checkboxes.
• Min value/
Max value
These fields define the values for the Minimum and Maximum fields for the prompts. For more information
on these fields, see Setting Minimum and Maximum Values for Prompts.
• Max length
Defines the maximum length of the data in characters. The value may not exceed 512 characters.
• Result Format
Used with Data Types with SQL statements and Multi Data Types. Determines how the SQL results are
formatted. Column numbers in { } are replaced by the value of that column. Other characters are included
unchanged. If this field is empty. Applications Manager uses the default value of {1}, which means that
it passes the value from the first column. The result format does not change the view when you click the
Check SQL button.
• Date input format/
Date output format
These two drop-down list boxes are selectable only when the value in the Type field is Date. They define the
input format for a date entered in a prompt and the output format at the time the program is executed. They
are used for date format verification and conversion.
• Referential checking
This option only exists for legacy customers. Its functionality has been replaced by Multi Data Types with an
intersection operation. For more information, see Using Multi Data Types.
• Upper Case
When this option is selected, Applications Manager converts all values to upper case characters.
• Distinct
When this option is selected, Applications Manager ensures that no duplicate values are returned. This is
primarily for PeopleSoft where distinct is not allowed in their SQL statements.
3. Depending on the value you select from the Type field, you may fill in the fields on either the SQL, Multi, List,
or File tab.
Because SQL Data Types are the most common, the fields on the SQL tab are described in the following table.
• Login
The Login you wish to run the SQL statement against. You can select:
• Database Login objects to execute the statement against a database.
• Agent type Logins to request information from an Agent's application. Agent type Logins are written in { }
brackets. For example, you can select {PSE} and Applications Manager will run that SQL statement using
the API connection it has to PeopleSoft. If two of the selected Agent types are defined, a pop-up window
will appear where you can select the Agent to run against.
This field becomes active when you enter a SQL statement below. If the Login is set to 'No Selection',
Applications Manager will use the Oracle Database Login used to connect to the Applications Manager
database. If the Login you wish to use is not included in the drop-down list, have your Applications Manager
administrator check its definition.
To evaluate dynamic Substitution Variables, Data Types, or Reports in a database other than the Applications
Manager database, the Login object must be defined for JDBC use. For more information, see the
Administration Guide.
• Use Requestor's Login
 Applications Manager 9.4.1

Uses the Login assigned to the User who requests an object that includes this data type. This option is
useful if you want to evaluate a data type's SQL statement based on either a User's view of a database or on
different databases depending upon the User. This checkbox is only active for Data Types where a Login is
specified. If a Login is not selected in the requestor's User definition, the Login set in the Login field on this
window will be used.
• SQL Statement
Contains a select statement which provides a list of values for a prompt. The SQL statement can be up to
2000 characters long. Each value can be no more than 100 characters long. The first value displays the
prompt's value. The second value provides additional information about the first value.
Although SQL statements can return values of various types, including numbers and dates, Applications
Manager evaluates them all as characters. Therefore, you must return your values as text. To convert a
number to text, use the to_char function. In the image above, the to_char(deptno) function converts the
department number to text.
The SQL allows the use of select Replacement Values to use with ad hoc requests. To insert Replacement
Values, click the { } button.
• Check SQL
Executes the SQL statement and displays the output in the SQL View window as shown below.
 Applications Manager 9.4.1

4. Optionally enter text on the ToolTip tab to display additional information about prompts when a user mouses
over them on the Submit window.

Using Multi Data Types

Multi Data Types allow you to use two data type objects to retrieve a prompt value from a list. The operation setting
determines which values are available.
 Applications Manager 9.4.1

Defining Multi Data Types

To define a Multi data type, select Multi in the Type field for the data type. On the Multi tab, select the two Data
Types you wish to use from the Data Type 1 and Data Type 2 fields and select an option from the Operation box.

To include: Select:

All values in from the Data Types selected as Data Union.

Type 1 and Data Type 2
 Applications Manager 9.4.1

To include: Select:

Only the values which are in both the Data Types Intersection.
selected as Data Type 1 and Data Type 2

Only the values in Data Type 1 which are not also in Minus.
Data Type 2

Importing Objects with Multi Data Types Prompts that Select AM Objects
When you export and import objects that use Multi Data Types that reference AM objects, only the objects that exist
on the target instance will be referenced after the import. Note that the reference numbers will be different on the
target instance than they were on the source instance.

Using List Data Types

List Data Types allow you to create prompts where users can select values from a list by adding items to the data
type rather than querying database tables for them.
Using List Data Types vs. Data Types with SQL Statements
When users can select prompt values from a list, the lists are generated by the prompt's data type in one of two
ways. The data type either:
• Includes a SQL statement that queries a database for values.
• Has 'List' selected as its general type and the date type includes the values in its definition.
As a general rule, you would use a SQL statement when tables already exist in a database for the values you
want users to select from. If database tables do not already exist for the selections, a List data type allows you to
manually enter values without the assistance of your DBA.
 Applications Manager 9.4.1

Defining List Data Types

To define a List data type, select List in the Type field for the data type. To add a list entry, select the List tab, enter
a value and description and click Add. You can delete entries by selecting an item and clicking Delete.

Using File Data Types

File Data Types allow you to select the files in a directory as a list of values.
 Applications Manager 9.4.1

Defining File Data Types

To define a File data type, select File in the Type field for the data type. On the File tab, enter the path to the
directory that contains the files you wish to appear in the list. This field allows you to use environment variables.

Using Password Data Types

Password Data Types allow users to enter passwords as prompt values. Password characters entered for prompt
values will be displayed as asterisks. Prompt passwords are encrypted.
 Applications Manager 9.4.1

Defining Password Data Types

To define a Password data type, select Password in the Type field for the data type.
Warning: If you use Password Data Types in prompts, they will be hidden on the client screen on the
Submit window. However, at the Job level the password needs to be provided to the program unencrypted.
You need to ensure the password is not displayed. The password is not displayed in the core Applications
Manager pieces, but the default Program Types do display all the parameters passed to a program. That
would include the password. Also, if debug is enabled, users may be able to see the password as an
environment variable.

Copying Prompts from Another Job or Process Flow

If you are creating a Job or Process Flow, you can copy the prompts defined in another Job or Process Flow rather
than having to recreate them from scratch. When you copy prompts, they are added to the prompts already defined
for the Job.
 Applications Manager 9.4.1

Procedure
To copy prompts from one Job or Process Flow to another:
1. From the Prompts tab for a Job or Process Flow, click the Copy button.
Applications Manager displays the Copy prompts window shown above.
2. Select the Job or Process Flow containing the prompts you want to copy.
You can filter the list by selecting an Application. Applications are groups to which Jobs are assigned. Only the
Applications, Jobs, and Process Flows assigned to you via User Groups will be displayed.
You can type the first few letters of a Job or Process Flow name in the Search field, and Applications Manager
will filter the list. If two Jobs or Process Flows start with the letter you type, Applications Manager highlights the
first one.
3. Click OK.
Applications Manager adds the prompts to the Job/Process Flow.

How Multi Select Prompts Work

When you submit a Job with a multi select prompt, Applications Manager writes a record in the so_multiselect
database table using a unique reference number for each selected value.
 Applications Manager 9.4.1

The reference number is passed to the script or application like any other prompt value. In order for a script or
application to use the values, it must retrieve the records from the database. You can retrieve records using a run-
time extension script, a Program Type script, or through the script or application called by the Job.
Example
When the JOB_RUN_REPORT Job shown above is requested, an end-user can select one or more Jobs to
see whether they have run within the last 24 hours. Once values are selected, Applications Manager assigns a
 Applications Manager 9.4.1

reference number to them. The reference number and values are stored in the so_multiselect table. The reference
number is also passed to the Job's script.
The so_multiselect table fields are described below:

Table field Description

so_ms_ref_no The ID number Applications Manager assigns to the

multi select prompt. This number will be the same for
each record generated by the prompt. It is displayed
in the Default column on the Submit window once the
values have been selected.

so_ms_source This field simply stores an R to show that the Job was
requested.

so_ms_value A value selected for the prompt. In the image above,

SYSTEM and TEST_JOB are the selected values.

so_ms_descr The description for each selected value.

When the job executes, it runs the jobsrun.sql script shown below. The jobsrun.sql script accesses the
so_multiselect table and returns the reference number and its values.

set verify off

title 'Modules run prior day'
spool &so_outfile
select so_module Module,so_status_name Status,
to_char(so_job_finished,'mm/dd/yyyy hh24:mi:ss') Finished
from so_multiselect b, so_job_history a
where so_job_finished between trunc(sysdate-1) and trunc(sysdate)
and a.so_module = b.so_ms_value
and b.so_ms_ref_no = &ms_list
/
spool off

When the Job completes, you can view its output with the File Viewer as shown below.
 Applications Manager 9.4.1

Retrieving Multi Select Values for Shell Scripts

The example above is used for SQL Jobs. To retrieve multi select values for shell scripts, use a statement such as
the following:

awexe multiselect_value arg_1=<so_ms_ref_no>

For more information on awexe commands, see Common awexe Commands You Can Use in Your Scripts.

Working with Substitution Variables and Replacement

Values
Substitution Variables (Subvars) let you store values that can be referenced in Applications Manager objects. The
values can be stored in a database table or generated by a SQL statement at the time a task is submitted. The
Substitution Variable window is shown below.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Substitution Variables. If you do not have access to them, see
your Applications Manager administrator.
You can add Subvars to:
• Prompts
• Conditions
• Other Subvars
• Output Scan rules
• Notification text
• Message Template text
• Output paths in Job, User, and Agent definitions
The ability to include dynamic Substitution Variables in conditions lets you control operations based on the state of
your corporate database, and automate processes to an extent not possible in a traditional operations environment.
Static and Dynamic Substitution Variables
There are two types of Subvars: static and dynamic. Values for static Subvars can be set by a User or a condition
with a SET SUBVAR action and stored in the Applications Manager database. Values for dynamic Subvars are
generated by a SQL statement when the Subvar is evaluated. The SQL for dynamic Subvars can run against
the Applications Manager database or any database you define for JDBC use. Subvars that run against the
Applications Manager database do not require a Login and are referred to as plain Subvars.
For information on defining static Substitution Variables, see Defining Static Substitution Variables.
For information on defining dynamic Substitution Variables, see Defining Dynamic Substitution Variables.
Substitution Variables That Ship with Applications Manager
Applications Manager ships with a number of Substitution Variables already defined. Several examples are listed
below.
• #current_year
 Applications Manager 9.4.1

• #day_of_week
• #first_of_month
• #first_of_last
• #last_of_last
• #last_of_month
• #next_monday
• #today
• #tomorrow
• #yesterday
Passing Values through a Process Flow with Numeric Substitution Variables
You also can create prompts for Process Flows to define values that will be used by the components added to the
Process Flows. You can pass prompts from a Process Flow to one or more components in the Process Flow using
numeric Substitution Variables. The values can be used in prompts, conditions, and aliases. The user can enter
values in one place and have them automatically used in one, several, or all of the components in a Process Flow.
This technique is described in Passing Values Through a Process Flow with Numeric Subvars.
Substitution Variables Evaluate as Strings or Numbers
Applications Manager evaluates Substitution Variables as strings or as numbers based on the qualifiers you specify
within your conditions. Dates can be evaluated as strings or numbers, but the data type selected in the Type field
will affect the Subvar's usage. To ensure proper evaluation of dates as numbers, use Julian dates (dates expressed
as the number of days elapsed since January 1, 4713 B.C.) or a YYYYMMDD format. The maximum return size for
a Substitution Variables is 512 characters.
Replacement Values
Replacement Values represent values assigned to Applications Manager objects that are stored in the Applications
Manager database. They come predefined when you install Applications Manager. Two frequently used
Replacement Values are {run_id} and {top_flow_id}. For a list of Replacement Values, see Replacement Value
Descriptions.
The { } brackets are used to evaluate Replacement Values within the SQL statement for a dynamic Substitution
Variables or in a condition that defines a Substitution Variables.
• For example: #task_number={run_id}
Warning: The { } brackets cannot be substituted with [ ] brackets. Substitution Variables written with [ ]
brackets will not be evaluated.

Defining Static Substitution Variables

Static Substitution Variables are stored in the Applications Manager database and retrieved when the Subvar is
evaluated. Static variables are generally used for sending information between Jobs. The information is usually
about Job status (for example: successful completion, aborted) or information about a Job (for example: file name).
 Applications Manager 9.4.1

Static Substitution Variables can be defined in the Substitution Variables window or by using the SET SUBVAR
action in a condition.
Defining a Static Substitution Variable
To define a static Substitution Variables:
1. From the Substitution Variables Selector window, click New.
Applications Manager opens the Substitution Variables window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Complete the fields using the information in the following table.
• Name
The name must start with a '#' sign. Names cannot contain blanks or start with numbers. They can be up to
30 characters long.
• Type
The data type, used to validate entries when this Substitution Variables is used in prompts. When you include
a Date type Substitution Variables in a prompt, the following settings must match:
• The Date input format/Date output format in the data type selected for the Subvar
• The Date input format/Date output format in the data type selected for the prompt
For more information on Data Types, see Defining Data Types.
• Value
The value for the variable may be up to 100 characters long. This field allows the use of dynamic Substitution
Variables. When dynamic Substitution Variables are used here, the value of the this Substitution Variables
will always resolve to the value of the dynamic Substitution Variables.
• Login
This field is only used for dynamic Substitution Variables. For more information, see Defining Dynamic
Substitution Variables.
 Applications Manager 9.4.1

The Login field, Use Requestor's Login box, SQL Statement box, Check SQL button, and Replacement
Values box are not used for static Substitution Variables. Dynamic Substitution Variables use SQL statements
to return values and perform activities such as retrieving sequences or logging a timestamp reference. For more
information, see Executing Procedures in Dynamic Substitution Variables.
Defining a Substitution Variable within a Condition
To define a Substitution Variables with a condition:
1. Choose the SET SUBVAR action as shown below.

2. Enter the name of the Substitution Variables, an '=' sign, and the value to be assigned to the variable. The name
must start with a '#' sign, cannot contain blanks, and can be up to 30 characters long. Do not put spaces around
the '=' sign.
The example shown above will create a Substitution Variables whose name will include a unique number
'{top_flow_id}' assigned to the Process Flow at run-time. The value of the Substitution Variables will be 'GO'.

Defining Dynamic Substitution Variables

Values for dynamic Subvars are generated by a SQL statement when the Subvar is evaluated. The SQL for
dynamic Subvars can run against the Applications Manager database or any database you define for JDBC use.
Dynamic Subvars that run against the Applications Manager database do not require a Login and are referred to
as plain Subvars. You can use dynamic Substitution Variables in conditions to evaluate the state of a database and
control Job/Process Flow execution. For example, you can check for the number of rows in a table, and delay the
Job if the count is less than 50. A dynamic Substitution Variables that returns the date of the first day of the month
is shown below.
 Applications Manager 9.4.1

Procedure
To define a dynamic Substitution Variables:
1. From the Substitution Variables Selector window, click New.
Applications Manager opens the Substitution Variables window shown above.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Complete the fields using the information in the following table.
• Name
The name must start with a '#' sign. Names cannot contain blanks or start with numbers. They can be up to
30 characters long.
• Type
The data type, used to validate entries when this Substitution Variables is used in prompts. When you include
a Date type Substitution Variables in a prompt, the Date output format in the data type selected for the
Subvar must match the Date input format in the data type selected for the prompt. For more information on
Data Types, see Defining Data Types.
• Value
Applications Manager ignores this field when you enter the SQL statement. For information on this field, see
Defining Static Substitution Variables.
• Login
The Login for the database you wish to run the SQL statement against. If the Login is set to 'No Selection',
Applications Manager will use the Oracle Database Login used to connect to the Applications Manager
database. Subvars that connect to the Applications Manager database are referred to as plain Subvars. If
the Login you wish to use is not included in the drop-down list, have your Applications Manager administrator
check its definition.
 Applications Manager 9.4.1

To evaluate dynamic Substitution Variables, Data Types, or Reports on a database other than the
Applications Manager database, the Login object must be defined for JDBC use. For more information, see
the Administration Guide.
• Use Requestor's Login
Uses the Login assigned to the User who requests an object that includes this Subvar. This option is useful
if you want to evaluate the Subvar based on either a User's view of a database or on different databases
depending upon the User. This checkbox is only active for dynamic Substitution Variables where a Login is
specified. If a Login is not selected in the requestor's User definition, the Login set in the Login field on this
window will be used.
• Replacement Values
Replacement Values retrieve information about Applications Manager stored in the Applications Manager
database. You can add Replacement Values to your SQL statement by highlighting a value and clicking
Insert. For more information on Replacement Values, see Replacement Value Descriptions.
• SQL Statement
The statement should query a database and extract a single (character type) value that will be used for the
variable. If the value is a number, you must use the to_char function to convert it to a character. The value
returned by the SQL statement must be no longer than 100 characters. The SQL statement cannot be longer
than 2000 characters.
Warning: When the Applications Manager Automation Engine is processing conditions, it stops
in the cycle to evaluate each SQL statement. Therefore, it is important that you write concise SQL
statements.
• Check SQL
Applications Manager runs the SQL statement as the Applications Manager Oracle user. The value returned
by the SQL statement is displayed below the SQL statement. For more information on modifying data, see
Executing Procedures in Dynamic Substitution Variables.

Executing Procedures in Dynamic Substitution Variables

Executing database procedures from Substitution Variables expands the versatility of dynamic Substitution
Variables. A reference to a dynamic Substitution Variables can return values and also perform other activities such
as retrieving a sequence or logging its own timestamp reference.
If dynamic Substitution Variables procedures perform lengthy operations, they will hold up other processes that are
waiting for the SQL to finish. If lengthy procedures are needed, they should be executed through a Job.
Sample SQL for Building a Procedure
The sample SQL below builds a database procedure called test_proc and gives the Applications Manager
Database Login execute authority:

CREATE or REPLACE PROCEDURE test_proc (field1 IN varchar2,

field2 IN varchar2,
field3 OUT varchar2) IS
BEGIN
field3 := field1||'='||field2;
END;
/
grant execute on test_proc to Applications Manager
/

Rules
Keep in mind the following rules when defining a procedure:
• A procedure must not contain more than one output field.
• If the procedure does not contain any output field, the dynamic Substitution Variables will return a NULL.
• A procedure may contain any number of input fields or none.
 Applications Manager 9.4.1

• The procedure should not perform lengthy operations.

• Be sure to grant execute on any procedures that are called with a synonym.
• The result output should not exceed 100 characters in length.
Required User Option
To use database procedures when defining Substitution Variables, you must have the Create Procedure SubVars
User Option assigned to you by your Applications Manager administrator.
Executing a Database Procedure in a Dynamic Substitution Variable
To execute a procedure in a dynamic Substitution Variables:
1. Open the Substitution Variables Selector window and click Add.
Applications Manager displays the Substitution Variables window shown below.

2. Enter a name for the variable.

3. Select data type 'Procedure.'
4. Leave the Value field blank.
5. Enter the procedure call statement, for example:

prod.test_proc('log.{requestor}','{run_id}',:result)

To return a value, the output argument of the procedure must be called :result as shown above. The
example procedure uses two Replacement Values: the Requestor ID and the run ID. It will return a string
that concatenates (combines) the two. The result would return 'log.SQLOPER=4022.00' for a task that was
requested by SQLOPER and whose run ID was 4022.
6. To save the definition and close the window, click OK.
 Applications Manager 9.4.1

Adding Subvars and Replacement Values to Applications Manager Objects

Substitution Variables and Replacement Values can be used in a number of places in Applications Manager. If a
field accepts Substitution Variables or Replacement Values, it will be followed by a { } button.
• Substitution Variables let you store values that can be referenced in various objects. The values can be stored in
a database table or generated by a SQL statement at the time a task is submitted.
• Replacement Values represent values assigned to Applications Manager objects that are stored in the
Applications Manager database. They come predefined when you install Applications Manager. For a list of
Replacement Values, see Replacement Value Descriptions.

In the image above, if the task does not complete successfully, the {condition1} Replacement Value is used to set
the value of the #task_status Substitution Variables to the status of the task. This Substitution Variables can then be
evaluated in other conditions.
Procedure
To add a Substitution Variables or replacement variable to a field with the Subvar Replacement Values window:
1. Click the { } button next to a field.
Applications Manager displays the Subvar Replacement Values window shown above.
2. Select one value from either list.
 Applications Manager 9.4.1

You can type the first letter of a value to highlight it.

3. Click OK to add the value to a field.
If the cursor is in the middle of a text string when you bring up the Subvar Replacement Values window,
Applications Manager will place the value at the cursor's position.
You can enter Substitution Variables/Replacement Values by typing the value into the field. Substitution Variables
are preceded by a '#'. Replacement Values are written inside curly braces, '{ }'.
Substitution Variables Evaluated as Characters or Numbers
Applications Manager evaluates Substitution Variables as characters or numbers depending on the qualifier value
used in the Condition Details window. For example, the condition #flow = bad will be evaluated as a string.
The condition #count_employees LE 100 will be evaluated numerically. For a complete list of string and numeric
qualifiers, see Selecting Condition Qualifiers.
To ensure proper evaluation of dates, use YYYYMMDD format with string qualifiers (>, <=, =) or Julian dates (dates
expressed as the number of days elapsed since January 1, 4713 B.C.) with numeric qualifiers (for example GE,
LE).

Replacement Value Descriptions

The table below provides a description for each Applications Manager Replacement Value.

Replacement Value Description

{Agent} The name of the Agent that the task is running under.
If a condition calls a Job that uses the {Agent} variable,
{Agent} refers to the parent Job's Agent.

{application} The Application assigned to the Job or Process Flow.

{application_path} The Library assigned to the Job. Not available for

Process Flows.

{batch_queue} Duplicate legacy Replacement Value. See {Queue} for

description.

{chain_id} Duplicate legacy Replacement Value. See {top_flow_id}

for description.

{chain_seq} Duplicate legacy Replacement Value. See {flow_seq}

for description.

{command} The name of the program run by the Job. The program
name is selected when defining the Job.

{command_path} The subdirectory specified for the Program Type

assigned to the Job. The subdirectory is specified in the
Command path field in the Program Types window.

{command_type} The Program Type assigned to the Job.

{condition1} The resolved value of the selection in the Condition

field. For example, if STATUS is selected in the
Condition field, the value of {condition1} will be the
task's actual status after it runs.
If USER DEFINED is entered in the Condition field, the
value of {condition1} is the resolved value of the first
field in the Test box. This Replacement Value can only
be referenced in conditions.
 Applications Manager 9.4.1

Replacement Value Description

{condition2} The value selected in the Test box that is compared to

the selection in the Condition box. This Replacement
Value can only be referenced in conditions.

{db_type} The database type for the Login assigned to the Job.

{engine} The name of the Automation Engine.

{email} The email address of the User/requestor of the Job or

Process Flow.

{fax_no} The fax number of the User/requestor of the Job or

Process Flow.

{file_line} The first line of the last file found by CHECK FILE. It
remains available until a CHECK FILE condition is run
for a different file.

{first} The first name of the User/requestor of the Job or

Process Flow.

{flow_seq} The Process Flow sequence number assigned to a

Process Flow when it is created.

{host_command} The name of the Program Type script run by the

Program Type assigned to the Job. For example: SQLP.
The scripts are usually located in the exec subdirectory.
The script is identified in the Host command field in the
Program Types window.

{Job} The Job definition name.

{Job_seq} The sequence number assigned to the Job when it is

created.

{jobid} Duplicate legacy Replacement Value. See {run_id} for

description.

{last} The last name of the User/requestor of the Job or

Process Flow.

{master} Duplicate legacy Replacement Value. See {engine} for

description.

{mjn} Duplicate legacy Replacement Value. See {Job_seq} for

description.

{module} Duplicate legacy Replacement Value. See {task} for

description.
Do Not Use {module} or {task} in Alias Names: Make
sure you do not use the {module} or {task} Replacement
Values in alias names. Doing so leads to circular
references where Tasks get stuck in Pred Wait status.

{net_connect} The connect string associated with the Login assigned

to the Job. The connect string is specified by the
Applications Manager Login.
 Applications Manager 9.4.1

Replacement Value Description

{node} Duplicate legacy Replacement Value. See {Agent} for

description.

{operator} Duplicate legacy Replacement Value. See {Agent} for

description.

{oracle_sid} The Login associated with the database assigned to the

Job. The database ID is specified by the Applications
Manager Login.

{phone_no} The phone number of the User/requestor of the Job or

Process Flow.

{Queue} The current Queue assigned to the task in the Backlog.

{requestor} The User assigned to the Job if it is submitted on an ad

hoc basis.

{run_id} A unique number assigned to a task by Applications

Manager when the task runs.

{seq_no} The sequence number assigned when each task is

launched.

{status} The task's status.

{subflow_id} A unique ID number generated for each instance of a

sub Process Flow. Used by:
• A sub Process Flow.
• The sub Process Flow's components.
Used to create a unique Substitution Variables
each time a sub Process Flow is run. Example:
#value{subflow_id}=success. For more information,
see Creating Local Substitution Variables Using
Replacement Values.

{task} The alias assigned to a task.

Do Not Use {module} or {task} in Alias Names: Make
sure you do not use the {module} or {task} Replacement
Values in alias names. Doing so leads to circular
references where tasks get stuck in Pred Wait status.

{text_msg} The text message email address of the User/requestor

of the Job or Process Flow.

{top_flow_id} A unique ID number generated for each instance of a

top level Process Flow. Used by:
• A Process Flow not called by another Process Flow.
• All of the Process Flow's components.
• All components at any level of any sub Process
Flows.
Used to create a unique Substitution Variables for a
Process Flow and all its children (and grandchildren,
etc.) each time the top level Process Flow is run.
Example: #value{top_flow_id}=success. For more
information, see Creating Local Substitution Variables
Using Replacement Values.
 Applications Manager 9.4.1

Creating Local Substitution Variables Using Replacement Values

When creating and assigning values to Substitution Variables in conditions, there is often a need for the
Substitution Variables to be specific or 'local' to a particular run of a Process Flow. This occurs most commonly
when a Process Flow is created that uses a Substitution Variables in its conditions and the Process Flow is run
several times simultaneously. There is the potential for the Substitution Variables to have its value overwritten and
adversely affect all runs of the Process Flow. To ensure each Subvar is unique each time the Process Flow runs,
use the {top_flow_id} Replacement Value.
Example
SVTEST is a Process Flow that includes three Jobs: MOD1, MOD2, and MOD3. Each Job runs by itself in the
Process Flow. MOD1 has two 'After' conditions that set Substitution Variables #flag to 'SUCCESS' if MOD1 finishes
successfully or 'FAILURE' if MOD1 aborts. MOD2 and MOD3 each have a 'Before' condition that tests #flag
and skips the Job if #flag is not set to 'SUCCESS'. If you run Process Flow SVTEST twice at the same time, the
following could happen:

Time SVTEST (Run 1) SVTEST (Run 2) #flag Value

1 MOD1 starts

2 MOD1 starts

3 MOD1 finishes SUCCESS

4 MOD1 aborts FAILURE

5 MOD2 skipped FAILURE, so skip

6 MOD2 skipped FAILURE, so skip

7 MOD3 skipped FAILURE, so skip

8 MOD3 skipped FAILURE, so skip

At Time 1, MOD1-Run1 starts. At Time 2, MOD1-Run2 starts. At Time 3, MOD1-Run1 finishes and its 'After'
condition sets #flag to 'SUCCESS' because the Job finished successfully. At Time 4, MOD1-Run2 aborts and its
'After' condition sets #flag to 'FAILURE' because the Job aborted. At Times 5-8, the 'Before' conditions on the
remaining Jobs all force a skip because #flag is set to 'FAILURE.' This is not the desired result—MOD2 and MOD3
for Run 1 should have run because MOD1-Run1 finished.
Solution
To avoid this problem, you need a Substitution Variables that is specific or 'local' to each run of SVTEST. You can
create such a Substitution Variables using the {top_flow_id} Applications Manager Replacement Value.
For each run of a Process Flow, the {top_flow_id} Replacement Value is a unique number. You can use this unique
number as part of the Substitution Variables name. It also helps to remember that Applications Manager will
automatically create Substitution Variables used in conditions if they don't already exist.
Below are several examples of conditions and how they can be improved with the {top_flow_id} Replacement
Value:

Without {top_flow_id} With {top_flow_id}

After: STATUS = FINISHED After: STATUS = FINISHED

SET SUBVAR #flag = SET SUBVAR #flag{top_flow_id} =
SUCCESS SUCCESS

Before: #result != SUCCESS Before: #result{top_flow_id} != SUCCESS

SKIP TASK SKIP TASK

After: ALWAYS TRUE After: ALWAYS TRUE

DELETE SUBVAR #value DELETE SUBVAR #value{top_flow_id}
 Applications Manager 9.4.1

In each case, the Substitution Variables (#flag, #result, #value) is augmented with the unique top_flow_id number
as part of its name. #flag might become #flag69, #result might become #result888, and #value might become
#value21107.
Making the Substitution Variables name unique for each run of the Process Flow eliminates any chance that
the Substitution Variables will be overwritten when a Process Flow runs concurrently with itself. There is one
caveat about using {top_flow_id} to uniquely name Substitution Variables. You must be sure to delete the unique
Substitution Variables when the Process Flow ends, otherwise you can end up with a large number of Substitution
Variables. For example, if a Process Flow that uses #flag{top_flow_id} in its conditions runs once an hour every
day, at the end of a week there would be 168 new Substitution Variables without a use. To delete a Substitution
Variables, add a DELETE SUBVAR condition at the end of the Process Flow at a position where the condition is
guaranteed to be evaluated. The condition must always evaluate true to guarantee the DELETE SUBVAR action is
taken. The table above contains an example of such a condition at the bottom of the With {top_flow_id} column.

Using Subvars and Replacement Values in Job and Component Prompts

Information on how Subvars and Replacement Values are used in Job prompts is presented below.
Using Subvars in Job and Process Flow Component Prompts
Prompts with Subvars in Job or Process Flow components will always be evaluated at run time regardless of
whether the Subvars include { } curly brackets. { } curly brackets are only used as delimiters in text strings. For
example, if {#aw_now}stamp is entered as a prompt value for a Job or Process Flow component, the prompt's
value will be the value of #aw_now at run time plus the text string stamp.
If you need to evaluate a Subvar in a task's prompt when it enters the Backlog, you can include the Subvar in a
Process Flow prompt and pass it to a component using a numeric Subvar. If it is a stand-alone Job that includes
this type of prompt, you can create a new Process Flow and add it as the only component. For information on
passing values from a Process Flow's prompts to its components, see topic Passing Values Through a Process
Flow with Numeric Subvars.
KIKIs:
• When bad SQL statements are included for a Subvar in a Job, Process Flow, or Process Flow component
prompt, the task will go to a LAUNCH ERROR status.
• When a Subvar name that doesn't exist is referenced in a Job, Process Flow, or Process Flow component
prompt, the string null is passed for prompt.
Using Replacement Values in Prompts
Replacement Values are always enclosed in { } curly brackets. Replacement Values included in Process Flow
prompt values are always evaluated when the Process Flow gets initiated. For example, if the Process Flow prompt
contains the {run_id} Replacement Value, it will evaluate to the Process Flow's run ID. If you want a Replacement
Value to be evaluated at the Process Flow component level, you cannot pass it from a Process Flow prompt. You
must include it as the prompt value for the component.

For example, if you want: Make the first Process Flow And the component prompt's
prompt's value: value:

To pass the value of the {run_id} {run_id} #1

Replacement Value when the
Process Flow is INITIATED to a
Process Flow component

The {run_id} Replacement Value to {run_id}

be evaluated when a Process Flow
component runs

Passing Values Through a Process Flow with Numeric Subvars

You can pass values from a Process Flow to its components. The values passed to a Process Flow come from
prompts added to the Process Flow. You can define up to 999 values. The values can be used in prompts,
conditions, and aliases (if you pass a prompt value to an alias, be sure it does not make the alias name greater
than 30 characters long—doing so will cause the component to abort). By using prompts, the user can enter values
in one place and have them automatically used in one, several, or all of the components in a Process Flow. Keep in
mind that numeric Substitution Variables are used in Process Flow components, they are not supported in Job and
Process Flow prompts or conditions.
 Applications Manager 9.4.1

The 'numeric Substitution Variables' #1, #2, #3......#999 are the link between the Process Flow and its components.
As you add prompts to the Process Flow, Applications Manager numbers them sequentially. When you add Jobs
and nested Process Flows to the Process Flow, you use the numbers assigned to the prompts in the Process Flow
in the component prompt fields and conditions.
The diagram below shows an example of a Process Flow called ACCOUNTING_PROCESS_FLOW. The five
prompts in the Process Flow allow the user to enter an accounting period, the first and last days of the accounting
period, and a region and department. Applications Manager stores these values in Substitution Variables #1, #2,
#3, #4, and #5.
Applications Manager 9.4.1
 Applications Manager 9.4.1

These values are passed to the components REPORT_A, REPORT_B, and REPORT_C which are Jobs in the
ACCOUNTING_PROCESS_FLOW by entering the appropriate Substitution Variables. In REPORT_A, the value for
the last day of the period is also used in a condition. The statement checks to make sure the current day is after the
last day of the period. If it is not, the report is aborted. REPORT_A also uses the date Substitution Variables from
the 'First day of period' prompt as its alias.
Prompt values can be used in any combination in any number of Jobs. For example, REPORT_C uses only
prompts #4 and #5. You also can mix numbered prompts with other types of prompts.
You can also use this method to pass values from a Process Flow to additional Process Flows nested within it.

Example: Passing Values Through a Process Flow with Prompts

The following example shows how prompt values can be passed through a Process Flow.
Assume you want to create three Jobs that run reports against the Applications Manager task history table. The
reports and their matching program names are shown below.

Job Name Description Program Name

REPORT_BATCH Lists all tasks by Queue report_batch.sql

REPORT_JOB Lists all tasks by Job report_module.sql

REPORT_REQUESTOR Lists all tasks by requestor report_requestor.sql

Each report has been written to accept start date and end date values. When you create the Jobs, you will define
prompts for the start and end dates. You will use Substitution Variables to provide default values for the dates.
When you create the Process Flow, you will create matching prompts for the start and end dates. When a user runs
the Process Flow on an ad hoc basic, they will enter the start and end dates, and Applications Manager will pass
the dates down to each report Job in the Process Flow.
Step 1: Define the Data Types
For this example, you would use the Dates data type, which comes predefined with Applications Manager.
Therefore, you would move on to Step 2.
You can create new Data Types to suit your needs. For more information, see Defining Data Types.
Step 2: Create the Jobs and Define the Prompts
To create the report Jobs and define the prompts:
1. Create the REPORT_BATCH Job as shown below.
 Applications Manager 9.4.1

2. On the Prompts tab, create two prompts, one for the start date and one for the end date, using the values
shown below.

Prompt # Data Type Description Variable name Default value

1 Dates Enter start date: Job_start_date #yesterday

2 Dates Enter end date: Job_end_date #today

3. Submit the Job to make sure the report runs properly.
4. Use the Job copy function to create the other two reports, being sure to change the program designation.
Step 3: Create the Process Flow and Add the Jobs
To create the Process Flow that runs the three reports:
1. Create a Process Flow and name it REPORTS.
2. Add the three report Jobs to the Process Flow.
Include each component in the same row so the tasks will process faster. This way if one of the Jobs fails, it will
not prevent the other tasks from running.
You can test the Process Flow by submitting it.
Step 4: Enter the Substitution Variables for the Job Prompts
To modify the Jobs in the REPORTS Process Flow to accept start and end dates passed through the Process
Flow, enter the following override values on the Prompts tab for each of the Process Flow components
(REPORT_BATCH, etc.):
 Applications Manager 9.4.1

Prompt # Value

1 #1

2 #2

The #1 and #2 tell Applications Manager to use the values from the first and second prompts of the Process Flow.

Step 5: Add Prompts to the Process Flow

To add prompts to be passed through the Process Flow:
1. From the Process Flow's Prompts tab, create a prompt for the start date and a prompt for the end date using
the values shown below.

Field Start Date Prompt End Date Prompt

Data type Dates Dates

Description Enter start date: Enter end date:

Variable name (leave blank) (leave blank)

Default value #yesterday #today

A variable name is not needed because the prompt values are passed to an Applications Manager Job, not a
program.
2. Select the Value required and Allow changes boxes.
 Applications Manager 9.4.1

Testing the Numbered Substitution Variables

To test the numbered Substitution Variables:
1. Using the Requests window, call up the REPORTS Process Flow you just created.
2. Accept the default values for the prompts, or enter different dates.
3. Submit the Process Flow.
4. Monitor the status of the Jobs from the Explorer window.
5. When the task completes, view the output from the three reports.

Using Prompt Values in Process Flow Component Aliases

You can display the value from a Process Flow prompt in the Alias field of a component in a Process Flow. The
alias is displayed in the Backlog and History at run time. To do this, add a Substitution Variables inside of curly
braces as shown below in the Alias field for a Process Flow component on the General sub-tab. You can combine
the Substitution Variables with text.
 Applications Manager 9.4.1

Procedure
To use the data a user enters from a prompt as an alias for a Process Flow component:
1. Create the Data Types, Jobs, and prompts for your Process Flow. For an example, see Example: Passing
Values Through a Process Flow with Prompts.
2. Enter the number in the Alias field on the General sub-tab of the Process Flow component for the prompt that
you would like to have displayed as the Job's name in the Backlog and History.
You must put curly braces around the prompt number to indicate that the alias includes a numeric Substitution
Variables. You can use the numeric Substitution Variables by:
• Just including the variable.
Example: {#3}
• Combining the Substitution Variables with text.
 Applications Manager 9.4.1

Example: {#3}text
• Combining the Substitution Variables with other Substitution Variables.
Example: {#3}text{#today}
Notes
Consider the following when passing Process Flow prompts to component aliases:
• If the component alias is not enclosed in { } curly brackets, it will be evaluated as a string.
• Components with aliases including { } curly brackets should not be defined as external predecessors for other
Jobs, Process Flows, and Process Flow components. The reason is that predecessors reference task names
and these components' names by definition will change, causing the predecessors to not ever be met.
• The Always evaluate Subvars in Process Flow prompts at component run times when scheduled
Automation Engine option has no effect on component alias names. For Subvars, the value is always resolved
when the task runs. For Replacement Values, the value is always resolved when the Process Flow is inserted
into the Backlog.
• It is possible for component alias values to not match the component prompt value. For example, you might
have {#aw_now} set at the Process Flow level. In that case, it will get evaluated when inserted in the Backlog
alias name but will not be evaluated for the prompt until the component is initiated.
• If the prompt value is passed from a parent Process Flow all the way down to the alias name of a component
in a nested Process Flow the prompt value for the nested Process Flow must be enclosed in { } brackets (in the
parent Process Flow's definition), and the alias name in the nested Process Flow must also be enclosed in { }
curly brackets (in the nested Process Flow's definition).

Passing Subvars in Process Flow Prompts to Components

The following describes the designed behavior for passing Subvars used in Process Flow prompts to Process Flow
components.
To pass the value of a Process Flow's prompts down to the components, you can include numeric Subvars
in Process Flow component prompts and conditions. For example, when #1 is entered as a Process Flow
component's prompt, the value of that prompt will be replaced by the value from the first Process Flow prompt.
The timing of the substitution is determined by whether the Always evaluate Subvars in Process Flow prompts
at component run times when scheduled Automation Engine option is checked and whether the referenced
Process Flow prompt is enclosed in { } curly brackets as described below:

When the Process Flow And the Process Flow is And the Automation The prompt value is
prompt value is a Subvar run: Engine option: determined:
that:

Includes { } curly brackets In any way Is checked or not When the component is
eligible to run.

Does not include { } curly With an ad hoc request Is checked or not On the Submit window.
brackets
With a schedule, awrun Is checked When the component is
request, or REQUEST JOB eligible to run.
condition
Is not checked When the Process Flow
goes to an INITIATED
status

KIKIs:
• Changing the Always evaluate Subvars in Process Flow prompts at component run times when
scheduled option requires you to stop and restart the RmiServer process. For directions on stopping and
starting the processes, see the Administration Guide.
• The use of { } curly brackets around numeric Subvars in component prompts results in the same behavior as
when there are no { } curly brackets around them. Therefore, entering #1 and #2 for your component prompt
values is exactly the same as entering {#1} and {#2}.
• The above behavior does not change for sub Process Flows and their components.
Examples
 Applications Manager 9.4.1

The table below documents how Subvars are passed from a Process Flow to its components when the Always
evaluate Subvars in Process Flow prompts at component run times when scheduled Automation Engine
option is not checked. When the Always evaluate Subvars in Process Flow prompts at component run times
when scheduled Automation Engine option is checked, all Subvars passed to Process Flow components are
evaluated when each component runs for scheduled tasks, and on the Submit window for ad hoc requests.

If you want a component's prompt Make the first Process Flow's And the component prompt's
value to be: prompt value: value:

The Subvar value of #aw_now when #aw_now #1

the Process Flow is INITIATED or
requested ad hoc

The Subvar value of #aw_now when {#aw_now} #1

the component is eligible to run

The Subvar value of #aw_now when #aw_now {#1}stamp

the Process Flow is INITIATED
or requested ad hoc, plus the text
string "stamp"

The Subvar value of #aw_now when #aw_now {#1} stamp

the Process Flow is INITIATED or
requested ad hoc, plus space(s) and
the text string "stamp"

The Subvar value of #aw_now when {#aw_now}stamp #1

the component is eligible to run, plus
the text string "stamp"

The Subvar value of #aw_now when {#aw_now} stamp #1

the component is eligible to run, plus
space(s) and the text string "stamp"

Special Rules for Subvars Including Logins

You can add Logins to Subvars to determine the database you wish to run the SQL statement against. When
Subvars used in Process Flow prompts have a Login assigned to them, the Always evaluate Subvars in Process
Flow prompts at component run times when scheduled Automation Engine option setting and use of { } curly
brackets are not taken into consideration. These Subvars are always evaluated when included in Process Flow
prompts in the following ways:

When the Process Flow is run: The prompt value is determined:

With a schedule, awrun request, or REQUEST JOB When the component is eligible to run. To have the
condition Subvar evaluated when the Process Flow goes into an
INITIATED status, see Passing Subvars with Logins as
Prompts for Scheduled Process Flows.

With an ad hoc request On the Submit window.

Passing Subvars with Logins as Prompts for Scheduled Process Flows

If you are passing a prompt value from a Process Flow to its components and the prompt value is a Subvar that
includes a Login, the Subvar will be evaluated for each component at its run time rather than when the Process
Flow goes to an INITIATED status. This is only the case in the exact scenario described above. For a full listing of
when Subvars are evaluated as prompt values, see Passing Subvars in Process Flow Prompts to Components.
One potential problem is that scheduled Process Flows that pass Login Subvars from their prompts to their
components could pass unwanted results, especially if the Process Flow had been staged for several hours.
To evaluate the Subvar when the Process Flow is goes into an INITIATED status, you need to add a condition to
the Process Flow to set the value of a static Subvar and use the static Subvar in your Process Flow components.
Example
 Applications Manager 9.4.1

Assume you want to pass a value for the number of orders in a SQLSRVR database using a Subvar named
#orders, which has a SQLSRVR Login assigned to it that is specified for JDBC use. The Process Flow is scheduled
and includes one prompt. The prompt's value is #orders. You want to evaluate the Subvar based on the number of
orders in the database when the Process Flow goes into an INITIATED status rather than when each component
runs. To do this you would add a BEFORE condition to the Process Flow like the one shown below.

Before the Process Flow runs, this condition creates a static Substitution Variables named #prompt1_{chain_id}
that stores the value of the #orders Substitution Variables when the Process Flow is initiated. The {top_flow_id}
Replacement Value ensures that the Substitution Variables created by this Process Flow will have a unique name.
The second condition shown below deletes the Substitution Variables after all the Process Flow's components
leave the Backlog.
 Applications Manager 9.4.1

On the component's Prompts sub-tab for the PROCESS_ORDERS Process Flow component shown below, the
static Subvar #prompt1_{chain_id} is included in the Value column.

Working with Conditions

Conditions control the execution of Jobs, Process Flows, or Process Flow components. Conditions can be
evaluated before, during, and after a task executes, or after a task is deleted. You can add, update, or delete
conditions for the particular running of a task from the Backlog. A Job with two conditions is shown below.
 Applications Manager 9.4.1

Using conditions, you can do such things as:

• Check the current time and put a task on hold if it is later than 5:00 A.M.
• Check if a file exists, and if it does not, wait 15 minutes and check again.
• Run the second Job if the first Job in a Process Flow completes successfully. Run the third Job if the first Job
aborts.
Conditions can apply to Jobs, Process Flows, or Process Flow components. By adding conditions to Process Flow
components, you can use a Job differently in several Process Flows, or even the same Process Flow. You can also
add, edit, or delete conditions for non-running tasks in the Backlog. When you do this, the changes are particular
only to that running of the task.
Applications Manager can evaluate the conditions assigned to a Job before, during, and after the Job executes,
and after a Job is deleted, depending on the timing in the condition's definition. Conditions are not evaluated
until the Job is submitted and displayed in the Backlog. This includes conditions that are evaluated before a Job
executes. This means all components in a Process Flow are displayed in the Backlog regardless of the conditions
assigned to them.
When a test defined in a condition is met, Applications Manager takes the action defined by the condition.
Applications Manager includes a number of actions. If you want to take more than one action based on an event,
you create multiple conditions, each with the same test but different actions.
Several example conditions are included at the conclusion of this chapter. For more information, see Using
Conditions to Accomplish Common Tasks.
Using Your Corporate Database to Control Operations
One of the more powerful features of Applications Manager is the ability to control operations based on the content
of your corporate database. By using dynamic Substitution Variables in conditions, you can make decisions based
on such data as:
• The number of records in a table.
• The total dollars represented by receivables.
• The date a database was last updated.
For information on including Substitution Variables in conditions, see Adding Subvars and Replacement Values to
Applications Manager Objects.
Using Job/Process Flow Conditions for Process Flow Components
 Applications Manager 9.4.1

You can use the conditions defined for Jobs or Process Flows when adding them to a Process Flow. To do
this, select the Use Job Conditions option for the Process Flow components. For more information, see Setting
Execution Options.
Bad Conditions
If Applications Manager evaluates a bad condition (for example a condition with a bad SQL statement), it will ignore
the condition and report it to the Automation Engine's log file. The Job's status will be set to BAD CONDITN.
Copying Condition Information from Tables
To copy condition text from a table in an Applications Manager window, click one or more rows and enter CTRL+C.
You must select the entire row. You can then paste the text into an email, word processor, etc.

How Applications Manager Processes Conditions

Applications Manager determines when each condition is evaluated based on its condition timing. There are four
condition timings; BEFORE, DURING, AFTER, and DELETED. The flowchart below shows the evaluation cycle
Applications Manager applies to each task's BEFORE conditions.
Applications Manager 9.4.1
 Applications Manager 9.4.1

An evaluation cycle consists of working through the flowchart above until the 'Run task' or 'End processing' step
is reached. Applications Manager runs through the evaluation cycle for a task until it completes executing and is
moved to History, or until it aborts. Applications Manager evaluates all conditions in the order they are listed with
the following exceptions:
• If a condition runs a task, Applications Manager ignores the remaining BEFORE conditions for that task.
• If a condition stops the evaluation cycle, all remaining conditions are ignored for the current cycle. For example
if a condition puts a Job on hold, all remaining conditions will be ignored until the next cycle.
• If you use the GOTO CONDITION action, the destination condition must come after the condition containing the
GOTO action.
Running BEFORE Conditions
When Applications Manager is ready to execute a task, it evaluates its BEFORE conditions. By default, a task will
run unless one of the BEFORE conditions modifies its eligibility.
Running DURING Conditions
While a task is running, Applications Manager evaluates its DURING conditions. The frequency that Applications
Manager evaluates DURING conditions is based on the DURING_WAIT variable setting.
When the Automation Engine has no processing to do, it sleeps for the number of seconds entered in the Sleep
time field for its Local Agent. At the end of each sleep cycle, the Automation Engine evaluates the DURING
conditions.
When the Automation Engine is processing, it checks the DURING conditions. The frequency that it checks them
is based on the setting for the DURING_WAIT variable in your awenv.ini file, located in the site directory. You can
modify the setting. The default is 60 seconds.
Setting a low DURING_WAIT value may impede performance without evaluating conditions more frequently.
If a task completes executing in a shorter amount of time than the setting for the DURING_WAIT variable, its
DURING conditions may not execute.
Running AFTER Conditions
After a task completes executing successfully or unsuccessfully, Applications Manager evaluates all AFTER
conditions. If a task is killed, AFTER conditions are still evaluated.
Running DELETED Conditions
If a task is deleted from the Backlog by a user, Applications Manager processes DELETED conditions and skips
any AFTER conditions associated with the given Job.

Adding, Editing, and Deleting Conditions

You can include conditions for Jobs, Process Flows, or Process Flow components. The Conditions tab for a Job is
shown below. The Conditions tab for Process Flows and Process Flow components looks the same.
 Applications Manager 9.4.1

Adding Conditions
To add a condition to a Job, Process Flow, or Process Flow component:
1. From the Conditions tab for a Job, or Process Flow, or Process Flow component, click New.
Applications Manager displays the Condition Details window shown below.
 Applications Manager 9.4.1

Complete the fields on the Condition Details window as appropriate.

For more information on completing the fields, see the following topics in this chapter.
2. To save the Job/Process Flow with the new condition, click OK.
Applications Manager adds the condition and automatically saves the Job/Process Flow definition.
If you decide you do not want to include the new condition in the Job/Process Flow definition, you must delete
the condition. If you click Cancel on the Jobs or Process Flows window after adding a condition, the condition
is still included.
Editing and Deleting Conditions
To edit or delete an existing condition, select the condition on the Conditions tab and click Edit or Delete.
Copying Conditions
To copy conditions from another Job or Process Flow, click the Copy button on the Conditions tab. Applications
Manager displays a Copy conditions window where you can select an existing Process Flow or Job and preview
the conditions.
Setting Conditions Order
To change the order of the conditions for a Job on the Conditions tab, select the condition you want to move and
click Up or Down. Conditions must remain with their timing group (BEFORE, DURING, AFTER, or DELETED).
Taking More Than One Action for an Event
 Applications Manager 9.4.1

You can define only one action for each condition. If you want to take more than one action based on the same
event, create multiple conditions with different actions and set the condition order on the Condition tab. If one
condition takes an action that cancels the task or Process Flow, be sure it is the last one in the related group. For
an example, see Triggering Two or More Actions on the Same Event.
Using Subvars in Condition Tests and Actions
Fields in the Test box for conditions (the condition_1 and condition_2 values) only need { } curly brackets if the
Subvar is part of a bigger string. For example TEST_{#1} or MOD_{#today} require { } curly brackets, but #1 and
#today do not.
In the Action field { } curly brackets are needed:
• When the value if part of a bigger string.
• Around numeric Subvars.
All Subvars in conditions are evaluated when the conditions run.

Selecting Condition Values

The conditions displayed in the Condition drop-down box are based on the selection you make in the Timing field.
The fields displayed in the Test box are based on the condition you select.

There are several sources of values for the conditions:

• You can select a value from a field with a drop-down box.
• You can enter a text string where allowed.
 Applications Manager 9.4.1

• You can select a Replacement Value or Substitution Variables for any field that includes the { } button.
Replacement Values retrieve values stored for Applications Manager objects, while Substitution Variables
represent one of many possible dynamic or static values stored in any designated database.
• If the USER DEFINED condition is selected, you can enter a numbered Substitution Variables (#1 - #999)
to accept a value passed down from a Process Flow when it is requested on an ad hoc basis. For more
information on passing values through a Process Flow, see Passing Values Through a Process Flow with
Numeric Subvars.

Selecting Condition Timing

You can set the timing for a condition to have Applications Manager check it before, during, or after a Job or
Process Flow executes, or after it is deleted. The option selected from the Timing drop-down box determines which
conditions are available.

Use the Timing field in the Condition Details window to control when Applications Manager checks for a
condition, and which conditions are available. Conditions with a common timing are often referred to by their group.
For example, a CHECK FILE condition with a BEFORE timing may be referred to as a BEFORE condition.
BEFORE Conditions
The condition is evaluated before the Job/Process Flow executes. The following are available as BEFORE
conditions:
• USER DEFINED
• ALWAYS TRUE
• CHECK CONNECTION
 Applications Manager 9.4.1

• CHECK FILE
• CHECK FILE FTP
• CHECK HISTORY
• CHECK PROCESS
• CURRENT QUEUE
• CURRENT TIME
• MODULE REQUESTED
• MODULE RUNNING
• TIME SINCE REQUEST
DURING Conditions
The condition is evaluated every time the Automation Engine checks the Backlog Queue (about once a minute)
while the Job/Process Flow is executing. The following are available as DURING conditions:
• USER DEFINED
• ALWAYS TRUE
• CHECK CONNECTION
• CHECK FILE
• CHECK FILE FTP
• CHECK HISTORY
• CHECK PROCESS
• CURRENT TIME
• RUN TIME
• TIME SINCE REQUEST
AFTER Conditions
The condition is evaluated after the Job/Process Flow executes, even if it aborts or is killed. The following are
available as AFTER conditions:
• USER DEFINED
• ALWAYS TRUE
• CHECK CONNECTION
• CHECK FILE
• CHECK FILE FTP
• CHECK HISTORY
• CHECK PROCESS
• CURRENT TIME
• RETURN CODE
• STATUS
• TIME SINCE REQUEST
DELETED Conditions
If a Job/Process Flow is DELETED, the conditions on the DELETED Job will be evaluated. This differs from
an AFTER condition. AFTER conditions are not evaluated for a DELETED task. The following are available as
DELETED conditions:
• USER DEFINED
• ALWAYS TRUE
• CHECK CONNECTION
• CURRENT QUEUE
• CURRENT TIME
• TIME SINCE REQUEST

Selecting Condition Types

The values available for the Condition field are determined by the Timing option you select. The condition you
select determines the fields displayed in the Test box. The values available for the Condition field are described
below. The letters in the Timing column stand for the following: B-Before, D-During, A-After, and R-Delete.
 Applications Manager 9.4.1

Condition Timing Description

USER DEFINED BDAR Provides two Test fields, separated

by a qualifier. You define the
condition by entering text strings
or numeral Substitution Variables,
or use the { } button to select
Substitution Variables/Replacement
Values.

ALWAYS TRUE BDAR Takes an action every time a

Job is run. This serves the same
purpose as entering 1=1 for a USER
DEFINED condition.

CHECK CONNECTION BDAR Checks whether a Login connection

exists or does not exist. When
selecting the Login, you can first pick
a Login type to filter the list.

CHECK FILE* BDA Checks if the file named in the

File Name field does or does
not exist based on maximum file
age, minimum unchanged time
(stability), and/or minimum file
size on the Agent where the Job
is running. Wildcards and spaces
are allowed if the fully pathed
file name is enclosed in double
quotes. Environmental variables
are allowed. When additional text
follows an environmental variable,
the environment variable should be
enclosed in { } brackets.
The first line of the last file found
by CHECK FILE is stored in the
Replacement Value {file_line}.
You might use the {file_line}
Replacement Value in a later
condition to check whether the file
included a text based error code and
set the task's status accordingly if it
did.
For a CHECK FILE example, see
Checking If a File Exists.
This condition type is not available
for Process Flows.

CHECK FILE FTP* BDA Checks if the file named in the File
Name field does or does not exist
on a remote host. You specify the
host by selecting a Host Login from
the at login field. Operating system-
specific wildcards are allowed.
 Applications Manager 9.4.1

Condition Timing Description

CHECK HISTORY* BDA Checks the status of the most

recent existence of a Job (but not a
(two options)
Process Flow) in History within the
• Success last days, hours, and minutes. Use
• Failure the Alias when referring to Process
Flow components. The condition is
evaluated as true if:
• Success is selected and the Job
has a status of FINISHED.
-or-
• Failure is selected and the Job
has a status of DIED, ABORTED,
KILLED, TIMEDOUT, or LAUNCH
ERROR
If the Job is not found, the condition
is evaluated as false. For an
example, see Checking for a
Finished Task in History.

CHECK PROCESS BDA Checks if another process is running

on the Agent where the Job is
running. For an example, see
Checking If a Process Is Running.
This condition type is not available
for Process Flows.

CURRENT QUEUE* BR Provides the value for the current

Queue definition.

CURRENT TIME* BDAR The current time in the format

HH:MM:SS.

JOB REQUESTED* B Checks if a Job or Process Flow

has been requested and is in the
Backlog.

JOB RUNNING* B Checks if a Job is in a running state

in the Backlog. To check for an
alias, type the alias name. For an
example, see Killing a Task That Is
Running Too Long.

RETURN CODE* A Reads the return code generated

by the program. Selectable only for
Jobs.

RUN TIME* D The wall clock time since the Job

started running.

STATUS* A Usually used to check whether a

task's status is equal to FINISHED.
This allows you to check if the
current Job completed successfully.
For an example, see Killing a Task
That Is Running Too Long.
 Applications Manager 9.4.1

Condition Timing Description

TIME SINCE REQUEST* BDAR Elapsed wall clock time between

the time the Job was requested and
the current time. Useful for checking
how long a task has been waiting in
the Backlog. For an example, see
Checking and Notifying the Time
Since Request.

*System function

Selecting Condition Qualifiers

Qualifiers are used to evaluate two values in the Test box fields of a condition as shown below. The condition you
select determines the qualifiers that are available from the drop-down box

Qualifier Types
The qualifier you select determines the way the condition is evaluated. The two types of qualifiers are:

Qualifier type Evaluates the condition values as:

String A left to right sequence of characters.

 Applications Manager 9.4.1

Qualifier type Evaluates the condition values as:

Numeric Mathematical statements.

If you select the wrong type of qualifier, Applications Manager may not evaluate your condition the way you intend
it to. For example, Applications Manager evaluates '1000 GT 50' as true (because one thousand is more than fifty),
and '1000 > 50' as false (because 1 does not come after 5 alphabetically).
Qualifier Descriptions
Qualifier descriptions are listed below.

Qualifier Type Description

!= or <> String Not equal—both signs evaluate the

same.

< String Less than.

<= String Less than or equal to.

= String Equal to.

> String Greater than.

>= String Greater than or equal to.

LK String Is like-uses a substring search to

check if the second value occurs in
the first. You might use this qualifier
to determine whether a substring
exists in a dynamic Substitution
Variables's value.

GE Numeric Greater than or equal to.

LE Numeric Less than or equal to.

GT Numeric Greater than.

LT Numeric Less than.

NE Numeric Not equal.

EQ Numeric Equal to.

Substitution Variables Evaluated as Characters or Numbers

Applications Manager evaluates Substitution Variables as characters or numbers depending on the qualifier value
used in the Condition Details window. For example, the condition #flow = bad will be evaluated as a string. The
condition #count_employees LE 100 will be evaluated numerically.
To ensure proper evaluation of dates, use YYYYMMDD format with string qualifiers (>, <=, =) or Julian dates (dates
expressed as the number of days elapsed since January 1, 4713 B.C.) with numeric qualifiers (for example GE,
LE).

Selecting Condition Actions

The values available for the Action field are listed below. The action values are determined by the selected Timing
option. In the table the letters in the Timing column stand for the following: B-Before, D-During, A-After, and R-
Delete. Some of the actions require that you enter additional information.
 Applications Manager 9.4.1

Action Timing Description

ABORT TASK* BA Aborts the current Job. Also see the

SET ABORT STATUS action.

CANCEL PROCESS FLOW* BDA Cancels all remaining non-running

components in the Process Flow,
plus any components in its parent
and child Process Flows.
This action should only be assigned
to Process Flow components. Do not
assign it to Jobs or Process Flows
that run outside of a Process Flow.

CANCEL SUB FLOW* BDA Cancels all remaining non-running

components in the Process Flow
that this component is a member
of. It does not cancel components
assigned to Process Flows which
are the parent of this component's
Process Flow.
This action should only be assigned
to Process Flow components. Do
not assign it to Jobs or a top level
process flow.

CHANGE Q BD Changes the Queue for this task.

Changing Queues does not affect
the Process Flow execution order.
The The first time the condition is
true radio button must be selected
for this action or the task will never
start.
Switching the Queue in the Backlog
will not disengage a component from
its Process Flow.

DELAY TASK* B Delays for a number of hours,

minutes, and seconds before the
task is run or before the condition is
evaluated again. HH:MM:SS format.
The time delay begins when the
condition is checked.

DELETE SUBVAR BDAR Deletes a static Substitution

Variables or multiple static
Substitution Variables when
wildcards are used. This action will
not delete dynamic Subvars.

EXTRACT VALUE BDAR Scans text and sets a Subvar based

on the results. For an example, see
Extracting Text from Files.
 Applications Manager 9.4.1

Action Timing Description

GOTO CONDITION BDA Skips to a condition by number.

Destination condition must follow
the condition containing the GOTO
action.
The GOTO number is not re-
sequenced when a condition is
moved.

HOLD TASK* B Changes the Job's status to HOLD.

Also see the SET HOLD STATUS
action.

KILL TASK* D Issues a Kill action on the task. If

this action is taken on a Process
Flow, the Kill action will be taken
on all running components in the
Process Flow.

REQUEST JOB BDAR Select the Details button to select

a Job and set its options. For an
example, see Requesting a Job or
Process Flow.

RESCHEDULE TASK* B Adjusts the start time of the task

today. HH:MM:SS format. If a time
earlier than current is entered, the
Job will run as soon as possible.

RESTART ON ABORT BDA Set or reset the Job's Restart once

on abort attribute. This action does
not alter the Job definition—it affects
the particular Job in the particular
Process Flow.
 Applications Manager 9.4.1

Action Timing Description

RUN HOST COMMAND BDAR Runs an operating system host

command, with arguments, on the
Agent of the Job (for example, cp
file1 file2).
When the RUN HOST COMMAND
condition action is invoked, the
specified command is issued as an
independent process by the Agent
of the task to which the condition
was defined. Once the command
has been issued, the condition
processor does not wait until the
host command completes. This is
the designed behavior to prevent
long running scripts from interfering
with condition processing. If the task
needs to wait for the completion of
the launched host command, one
or more additional conditions may
be required to assure the script has
completed. An additional condition
type might be CHECK PROCESS
(with a WAIT UNTIL MET action)
if the host command had a unique
name which was visible when it is
running, or possibly CHECK FILE
(with a WAIT UNTIL MET action) if
the script writes an output file when
complete.
If the HOST COMMAND was
something like echo x>my.file
followed by a CHECK FILE condition
which looked for my.file, the CHECK
FILE condition might not find the
file because the HOST COMMAND
may not have completed before
the CHECK FILE condition was
executed.
For more information, see your OS
documentation.
This condition action is not available
for Process Flows.

RUN TASK* B Runs the task. Any remaining

'Before' conditions are ignored.

SEND JMS MESSAGE BDA Select the Details button to specify

a JMS message to send. For
an example, see Defining JMS
Messages with Conditions.

SEND NOTIFICATION BDA Sends a Notification via email or

Output Device using an Applications
Manager Notification object. For
an example, see Checking and
Notifying the Time Since Request.
 Applications Manager 9.4.1

Action Timing Description

SET ABORT STATUS* A Sets Job status to ABORTED and

displays custom text as status
name. Allows for a maximum of 12
characters.

SET FINISHED STATUS* A Sets Job status to FINISHED and

displays custom text as status
name. Allows for a maximum of 12
characters.

SET HOLD STATUS* B Sets Job status to HOLD and

displays custom text as status
name. Allows for a maximum of 12
characters.

SET SKIP STATUS* B Sets Job status to SkipCond and

displays custom text as status
name. Allows for a maximum of 12
characters.

SET SUBVAR BDAR Creates a static Substitution

Variables. To create a unique
Substitution Variables for a Process
Flow, include the {top_flow_id} or
{flow_seq} Replacement Value.
To create a unique Substitution
Variables for a Job, include the
{run_id} Replacement Value. For
a description of Replacement
Values, see Adding Subvars and
Replacement Values to Applications
Manager Objects.
When the new Subvar is added to
Applications Manager, it will only be
assigned to the DBA User Group.

SKIP TASK* B Sets the Job or Process Flow's

status to SkipCond. Also see the
SET SKIP STATUS action.

STAY IN QUEUE ON ABORT BDA Sets or resets the Job's Stay in

Queue on abort attribute. This action
does not alter the Job definition—it
affects the run of the particular Job
in the particular Process Flow.

WAIT UNTIL MET* B Causes the task to pause until the

condition is met. In other words, the
wait action is taken each time the
condition is FALSE. This action is
the most expensive action because
BEFORE or DURING conditions
are evaluated as often as every
30 seconds until the task starts or
finishes. A much better action in
most cases is to use the DELAY
TASK action set to 00:05:00, which
would cause the Job to delay
condition checking for five minutes.
 Applications Manager 9.4.1

*Stops processing Job conditions for the current evaluation cycle and will not start the task this evaluation cycle.

Selecting Action Timing

Applications Manager evaluates conditions for a Job at least every 59 seconds. However, you select how often
the action for each condition should be taken by selecting a radio button from the Action Timing box as shown
below. So, even though a condition may be evaluated multiple times, the action may be taken only the first time the
condition is true.

The action timing radio buttons are described below.

• The first time the condition is true
Applications Manager only initiates the specified action the first time the condition is true and changes its action
timing to Disabled. After that, Applications Manager skips the condition.
You might use this option for a condition that notifies an operator when a Job has failed. If there are events that
cause the condition to be evaluated as true a number of times, Applications Manager won't send out a new
message every time.
• Every time the condition is true
Applications Manager initiates the specified action every time the condition is true.
This setting is used often with the DELAY TASK action. For example, you might use this option if you want Job
'Y' to execute only after another Job 'X' has completed. You could check for the status of Job 'X', and if it has not
completed, use the DELAY TASK action to delay Job 'Y' by 15 minutes. You would want to use the delay each
time the condition is true.
• Disabled
 Applications Manager 9.4.1

Applications Manager will skip the condition.

You might use this option if you write a condition, but do not want to activate it.
The action timing for conditions with The first time the condition is true selected will change to Disabled
when the action is taken.

Copying Conditions from Another Job, Process Flow, or Component

If you are creating a Job or Process Flow, you can copy one or more conditions defined in another Job, Process
Flow, or Process Flow component rather than having to recreate the conditions from scratch.

Procedure
To copy conditions from one Job, Process Flow, or Process Flow component to another:
1. From the Conditions tab for a Job, Process Flow, or Process Flow component, click the Copy button.
Applications Manager displays the Copy conditions window shown above.
2. Select the Job or Process Flow containing the conditions you want to copy.
You can filter the list by selecting an Application. Applications are groups to which Jobs are assigned. Only the
Applications, Jobs, and Process Flows assigned to you via User Groups will be displayed.
You can type the first few letters of a Job or Process Flow name in the Search field, and Applications Manager
will filter the list. If two Jobs or Process Flows start with the letter you type, Applications Manager highlights the
first one.
If you want to copy conditions from a component in a Process Flow, select the Process Flow from the Jobs/
Process Flows table, then pick the component name from the Components drop-down list.
3. Once you select a Job or Process Flow (and possibly component), select the conditions you wish to add.
 Applications Manager 9.4.1

To select multiple adjacent conditions, use Shift+click. To select multiple non-adjacent conditions, use Ctrl+click.
4. Click OK.
Applications Manager adds the conditions to the Job, Process Flow, or Process Flow component.

Using Conditions to Accomplish Common Tasks

The previous topics in this chapter described how Applications Manager evaluates conditions and the values
available for them. The topics that follow give examples of how conditions can be used in various Jobs, Process
Flows, and Process Flow components.

Checking and Notifying the Time Since Request

If you have scheduled a task to run at a specific time, you may want to set up a condition that uses an Applications
Manager Notification object to alert someone via email, pager, or other Output Device that the task has been
waiting in the Backlog too long.
You select a Notification by picking the SEND NOTIFICATION action, clicking Details and picking a Notification
from the Notification window. The statuses listed in the status box tell you when the Notification would be
automatically run for a task if it were assigned to that task's Application, Program Type, or Job definition.
When 'Condition' is set as the status for a Notification, it is intended to be assigned to a condition with a SEND
NOTIFICATION status.
The settings shown below will run the WAITING2LONG Notification if the task has been waiting more than 30
minutes. For more information on Notifications, see Defining Notifications.

The Timing is set to BEFORE, so the check will be made before the Job is executed.
The first time the condition is true is selected because the Notification action only needs to be taken once.
You may additional or alternately wish to abort a task if it runs too long. This can be accomplished by defining a
condition with an ABORT TASK action.
 Applications Manager 9.4.1

Checking If a File Exists

Some Jobs need to wait for the creation of one or more files before executing. You can check for the existence of a
file (considering age and size) using the CHECK FILE condition.
If a Job in a Process Flow needs to wait for the creation of a file before executing, you can delay the Job until the
necessary output file is available.
Many times, however, a check for a simple file is not enough. The required file may need to be a certain size, or
the file may need to have been created within the last 24 hours to be valid. In addition to checking for a file by file
name, you can check for files using environment variables and wildcards, specifying maximum acceptable age or
minimum acceptable stability (of the file based upon the last modification date/time of the file), and specifying the
minimum acceptable size.

The CHECK FILE and CHECK PROCESS conditions are special in that they can evaluate as true based on
whether a file/process exists or does not exist.
A sample CHECK FILE condition is above. Every time the condition is true is selected, so the condition will be
checked, and if true delay five minutes and check again, even after it has already been delayed.
The condition shown above will evaluate to true when it does not find any single file in the $AW_HOME/out
directory that has a rep extension, has not changed for at least 180 seconds, is less than 1 day old, and is larger
than 10,000 bytes.
Double Quotes for Spaces and Wildcards
When using spaces and/or wildcards, the fully pathed file name should be enclosed in double quotes.
 Applications Manager 9.4.1

When using wildcards, onlyone file needs to match the wildcard, age, size, and stability requirements for the
condition to evaluate to TRUE.
Using the {file_line} Replacement Value
The first line of the last file found by CHECK FILE is stored in the Replacement Value {file_line}. You might use the
{file_line} Replacement Value in a later condition to check whether the file included a particular text based error
code and set the task's status accordingly if it did.
Field Descriptions
The CHECK FILE fields are described below:
• File Name
The fully pathed file name you want to check for. This field allows the following:
• In the path: you can use environment variables and spaces.
• For the file name: you can use environment variables, spaces, and '*' wildcard characters.
Wildcards and spaces are allowed if the fully pathed file name is enclosed in double quotes. Environmental
variables are allowed. When additional text follows an environmental variable, the environment variable should
be enclosed in { } brackets.
• Exists/Does Not Exist
Determines whether to check if a file exists or does not exist. Choosing Exists will allow the use of the fields
listed below.
• Days/Hours/Minutes
These fields can be used to specify a maximum acceptable age for the file. The fields will accept values up to
99. If the last modification date/time of the file is older than this setting, the file is considered nonexistent and the
condition will evaluate as false.
• And has not changed for ______ seconds
Specify a minimum time (in seconds) for which the file must have been stable (unchanged). The field will accept
values up to 999. If the file has been modified more recently than the number of seconds specified, the file is not
stable. An unstable file is considered nonexistent and the condition will evaluate as false.
• And has a minimum size of ______ bytes
Specify a minimum acceptable size (in bytes) for the file. The field will accept values up to 9999999 (10
megabytes).
If the file is smaller than this setting, the file is considered nonexistent and the condition will evaluate as false.

Checking If a Process Is Running

Some Jobs need to have another process running before they will start. This may include checking Oracle PMON,
SMON, or DBWR processes. You can check if a program is running using the CHECK PROCESS condition. You
can check for the process's existence and take appropriate actions depending on the results.
CHECK PROCESS is executed on the Agent where the Job is running or is going to run.
If a Job or a Process Flow should not run while a backup is executing, a condition should be defined to check if the
backup process is still running, and wait until it finishes.
A sample CHECK PROCESS condition is shown below. Every time the condition is true is selected because the
DELAY TASK action needs to be taken each time Applications Manager processes the transaction.
 Applications Manager 9.4.1

Checking for a Finished Task in History

The CHECK HISTORY condition can be used to check History for the most recent existence of a Job (but not a
Process Flow) with a success or failure status within a given time period of days, hours and minutes. If there is
more than one instance of the task, the time period is based on the finish date and time of the most recent task.
A sample CHECK HISTORY condition is shown below. The first time the condition is true is selected when the
WAIT UNTIL MET action is selected.
 Applications Manager 9.4.1

The condition shown above will wait until it finds an FTP_TRANSFER task with a FINISHED status in History in the
last 45 minutes.
Field Descriptions
The CHECK HISTORY fields are described below:
• Job/View Name
The Job name or alias of the (most recent) task to check.
• Success/Failure
Determines whether the check is made for a successful task or a failed task.
Successful is defined as a task with a status of FINISHED; failed is defined as a task with a status of DIED,
ABORTED, KILLED, TIMEDOUT, or LAUNCH ERROR.
• Days/Hours/Minutes
These fields can be used to specify a maximum acceptable age for the task. The fields will accept values up to
99.
If the finish date and time of the task is older than this setting, the condition will evaluate to false.
CHECK HISTORY is available as a BEFORE, DURING and AFTER condition. Any of the available actions may be
used with CHECK HISTORY.
 Applications Manager 9.4.1

Killing a Task That Is Running Too Long

A Job that is taking too long to execute often indicates a problem. You can use the RUN TIME condition to check
on a Job and issue an abort command if it has run longer than a specified time.
You generally know how long it should take a Job to complete executing. Some Jobs may take only a few minutes,
while others may take several hours. If a Job has been executing for longer than expected, it usually indicates a
problem. You can use a condition to check on how long a Job has been running and cancel the Job if it is running
longer than expected.
The settings shown below check to see if the run time is greater than 30 minutes. If it is, Applications Manager kills
the Job.
The first time the condition is true is selected, because the Job only needs to be killed one time.
The RUN TIME condition is automatically checked for running tasks. It is only available when the Timing field is set
to DURING.

Related Topic
Another way to abort a Job if it has run too long is by entering a value in the Max run time field on the Job's
General tab. For more information, see Entering Execution Options for Jobs.

Requesting a Job or Process Flow

There may be times when you wish to call a Job or Process Flow as a condition's action. You can do this using the
REQUEST JOB action.
 Applications Manager 9.4.1

The settings shown below check whether a task has completed with a FINISHED status, and requests the Job
NOTIFY_SMITH if it has not.
The first time the condition is true is selected because Smith only needs to be notified once.

The REQUEST JOB action has been expanded to provide the same capabilities as the expanded awrun utility.
The options and prompts for submitting a task are selectable in the Job Details window. To access the Job
Details window, click Details as shown above.
Field Descriptions
The field descriptions are listed below. When 'Default' is selected, Applications Manager uses the value from the
Job/Process Flow's definition.
• Job
The Job to request when the action is taken.
• Requestor
The requestor (User) for the Job.
• Agent
The Agent on which to run the Job.
• Alias
Alias for the Job. You can use Replacement Values and Substitution Variables in this field. Alias names need { }
curly brackets if part of a bigger string.
• Priority
Priority of the Job relative to other Jobs in the same Queue. If nothing is entered in this field, Applications
Manager will use the setting defined in the Job, or you can specify a value in the range 0-99. Lower numbers
are higher priority. Zero means no priority; the Job will not run.
• DB Login
 Applications Manager 9.4.1

The Login for the Job.

• Maximum Run Time
Maximum time the Job is allowed to run. If the Job runs longer than this amount of time, it will abort.
• Stay in Queue on Abort
Determines whether the Job should stay in the Backlog if it aborts.
• Restart once on Abort
Determines whether to automatically restart the Job once if it initially aborts.
• Use Prompt Defaults
Determines whether the Job's default prompt values will be used when no value is specified for a prompt.
• Insert Job into this Process Flow
Includes the requested Job in the existing Process Flow (if the originating task is a Process Flow or Process
Flow component). If the alias is a duplicate it will be renamed by appending an underscore and a three digit
number (determined from the number of components now in the Process Flow) at the end of its original alias or
name. If requested from a component, the REQUESTED MODULE will be inserted as a clone of the originating
Job. It will inherit both its predecessors, so it shows in proper place in the Process Flow diagram, and its
"Success" successors. Anything waiting for Success of the originating task will also wait for the new component
to complete.
Selecting Prompts and Submit Options
Prompts and submit options are included on the Prompts tab. Numeric Subvars used in these prompts need { }
curly brackets around them.
Specifying Rapid Automation Field Values and Prompts for REQUEST JOB Requests
You can specify an RA Job field value in the following format with as many space separated XML names and
values as you wish. You can get the XML field name for a field but resting the mouse over the field name in the
client and reading the ToolTip.

<xml name>=<value>

You can specify RA prompt values in the following format.

prompt_<row number>_<column number>=<value>

Row and prompt numbers start at 0. For example, to edit prompt 3 in the GURPDED Job shown below, you would
enter the following awrun command:

prompt_2_3=YOURUSER

The sane syntax is used for awrun requests of RA Jobs.

 Applications Manager 9.4.1

Triggering Two or More Actions on the Same Event

You can assign only one action to a condition. However, you can assign many actions to the same event by using
multiple conditions. In this example, the first condition will notify Pat Brown, the system administrator, that the
Process Flow is being canceled, and the second condition will cancel the Process Flow.
 Applications Manager 9.4.1

Both conditions have the Timing set to AFTER, so Applications Manager will evaluate them after the task has
executed.
The action timing is set to The first time the condition is true for both conditions because the conditions are checked
after the Job runs.
The order of the two conditions is important because the CANCEL PROCESS FLOW action stops condition
processing. If the CANCEL PROCESS FLOW action comes before the RUN HOST COMMAND action, the latter
condition will not be executed and Pat will not be notified.
 Applications Manager 9.4.1

Running One Job Based on the Failure of Another

You want a certain Job, call it XYZ, to run if and only if another Job has failed in the last 30 minutes. The CHECK
HISTORY condition examines History for a task with a specific name and status within an allotted time.
You will need two conditions on Job XYZ to implement the requirement correctly: one condition to execute the Job if
the failed task is found, and another to otherwise skip the Job.
The Timing is set to BEFORE, so Applications Manager will check the conditions before the Job is executed.
Both conditions have The first time the condition is true set, because the RUN TASK and SKIP TASK actions only
need to be taken one time.
The order of the two conditions is important because the RUN TASK and SKIP TASK actions stop condition
processing. If the RUN TASK action comes after the SKIP TASK action, the Job will never be executed.
The first image below shows the CHECK HISTORY condition with the RUN TASK action. CHECK HISTORY will
check History for a failed FTP task. If the failed FTP task is found, the condition is true. The Job will run and the
second condition will NOT be evaluated.
The condition in the second image will only be evaluated if the first condition is false. If the first condition is false,
you want to skip the Job.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Extracting Text from Files

EXTRACT VALUE condition actions scan files and set Subvars from the text they find. You can extract values from
external files, or from the system output files or report output files created when a task runs.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Extracting values is a multi-step process:

1. Select the file type/name.
2. Optionally determine a number of lines to offset to begin the search.
3. Specify the string to scan for and specify search criteria for the scan.
4. Specify which text to set for the Subvar's value.
5. Name the Subvar.
Procedure
To scan a file and set a Subvar:
1. Define a condition with EXTRACT VALUE as its condition action.
2. Click the Details button to define the condition details.
Applications Manager opens the Extract value window shown above.
3. Select the file type you wish to scan from the File filter criteria box.

To scan for: Select:

A file not registered with the Applications Manager External files

Job.

An Applications Manager system output file. System files

A report file from the Applications Manager Job. Report files

If you select External files or Report files, you must specify the file name in the File filter field. If you select
System files, Applications Manager scans the first system output file Applications Manager creates for a task.
The File filter field allows the use of regular expressions.
You can use Subvars and Replacement Values in these fields. For example, b.{run_id}.
4. Optionally determine a number of lines to offset from the top or bottom of the file in the Start search at line
offset field to begin the search. Applications Manager offsets from the top of the file, unless you check the From
end of file box.
5. Select the text to search for the first instance of a string, or for the first instance of a string following another
defined text string. By default Applications Manager makes each search from the top to bottom of the file, but
you can choose to make any portion of the search go up instead. This allows for versatile searches.
Consider the following examples. Note that quotes are included to signify field values in these examples:

To: Do this:

Scan for the first instance of the word "Invoice" (with a Enter "Invoice" in the Primary search field and click
capital I) the Match case box.

Scan for the last instance of the word "total" Enter "total" in the Primary search field, and click the
Search Up box.

Scan for the first instance of the word "subtotal" Enter "total" in the Primary search field, "subtotal" in
coming before the word "total" the Secondary search field and click the Search Up
box to the right of the Secondary search line.

The Primary search and Secondary search fields allow the use of regular expressions.
 Applications Manager 9.4.1

6. If the value you wish to set for the Subvar will be found on a different line than the text you scan for, enter a
number of lines to move down or up in the Line offset field. Applications Manager will move down unless you
check the Search Up box to the right of the Line offset field.
7. Next, in the Formatter selection box, you will select the text you wish to enter as the Subvar value.

To create the Subvar based on: Select:

A range of characters Position formatter and enter a start and end

character number for the line. For example, entering
12-15 will create a Subvar from the twelfth through
fifteenth characters of a line.

In the sample text below, 0896 are the twelfth through

fifteenth numbered characters in the line:

Order num: 0896

 Applications Manager 9.4.1

To create the Subvar based on: Select:

Beginning and ending characters Delimiter formatter and enter the beginning and
ending characters. For example, you could enter "now
" and " orders" as delimiters.

With these delimiters, Applications Manager would set

a subvar to 253 based on the sample text below.

There are now 253 orders

If no end value is specified, the subvar value will

include every character until the end of the line.
Putting two values as start values in { } brackets
allows you to specify the occurrence of a second
value that follows the first. For example, you could
enter "{today's date} {total = }" as the start value and
"." as the end value.

In this case, Applications Manager would set the

subvar value to 1004.

Monthly total = 46323.18.

Today's date 1/31/06, total = 1004.

Were it not for the first starting value {today's date},

the subvar value would be 46323.

8. If necessary, enter any characters you do not want included in the Subvar definition in the Remove characters
field.
For example, if you don't want semicolons to be include in the Subvar definition, you would enter a ";" in the
Remove characters field.
9. Enter the Subvar name in the Subvar name field.
To give it a unique name each time the Subvar is created, include the {run_id} or {top_flow_id} Replacement
Values in the Subvar name. Doing so will require you to delete the Subvars you create manually or with a
condition.
If Search Text is not Found
If the search text is not found, the Subvar will be created with a null value.
Testing Your Results
 Applications Manager 9.4.1

If you are scanning an external file, you can test your results using the Test button. When testing, you specify
the Agent machine to search on, and Applications Manager displays the results in a Results window like the one
shown below.

You can also test the results on system or report files by selecting the External Files radio button and entering the
path to an output file for a completed Job in the File Filter field. After you are satisfied with the results of the test,
you can set the condition back to search system or report files.

Writing to the System Output File when Tasks Run Longer than Average
Using a custom Subvar and a condition with a RUN HOST COMMAND action, you can write to a task's system
output file when it runs longer than its average run time.
Creating a Subvar to Check Average Run Time
To get the average run time for a task, create a Subvar with the following SQL:

select to_char(so_avg_runtime) from so_job_table where so_module = '{task}'

A sample Subvar is shown below.

 Applications Manager 9.4.1

Writing to the System Output File

To write a message to the system output file for a task, create a condition with a RUN HOST COMMAND action
with host command like the following:

echo "passed average runtime" >> ./out/o.{run_id}

A sample condition is shown below.

 Applications Manager 9.4.1

Scheduling Jobs and Process Flows

With Applications Manager, you can create schedules to run Jobs and Process Flows that account for days of the
week, specific days of the month, and days in a Calendar. A Job or Process Flow may have multiple schedules.
The Schedule tab has four sub-tabs: General, Frequency, Exceptions, and Prompts.
 Applications Manager 9.4.1

Adding, Editing, and Deleting Schedules

You add schedules by clicking the New button and completing the information on the four tabs: General,
Frequency, Exceptions, and Prompts. Selecting a schedule from the list will show its detail in the Schedule tabs.
To edit a schedule, click Edit. To delete a schedule, click Delete. For more information, see Adding, Editing, and
Deleting Schedules.
Reviewing Schedules
After defining one or more schedules, you can review a twelve-month view of the schedule(s) by clicking the
Display button. For more information, see Displaying Run Dates for Schedules.
Running Multiple Jobs/Process Flows on the Same Schedule
Schedules are not Applications Manager objects. They are particular to a single Job or Process Flow. If you want to
use the same schedule for multiple individual Jobs and/or Process Flows, you can create a 'master' Process Flow
and add the Jobs and Process Flows to the Automation Engine Process Flow. If you add all the Jobs and Process
Flows to the same row in a Process Flow, they will all run at the same time.
Scheduling Behavior After an Outage
Applications Manager has built-in logic to recover quickly after a system crash or an outage. By checking the
values of the Start times and Next run date fields in each Job and Process Flow schedule, Applications Manager
determines when each task should run next.
 Applications Manager 9.4.1

If a Job or Process Flow should have run during the outage, it will be eligible to run immediately. If a Job or Process
Flow should have run several times during an outage, Applications Manager runs it once and returns it to its current
schedule. If a Job or Process Flow is not eligible to run on a particular day after an outage, but it was scheduled to
run on a day during the outage, it will run immediately after the recovery.
There is an option to defer all scheduled tasks while the Automation Engine is stopped. For more information, see
Skipping Scheduled Tasks While the Automation Engine Is Stopped.
Eligibility
Before running a scheduled Job or Process Flow, Applications Manager checks its:
• Schedule
• Active Job/Process Flow setting
• Predecessor links
• Automation engine, Agent, and Queue capacity
• BEFORE conditions
All of these must be satisfied before the Job or Process Flow will run. For a full list of actions a task takes, see
Appendix C: Task Action Order.

Adding, Editing, and Deleting Schedules

For most schedules, you only need to complete the information on the General and Frequency tabs.
To define a new schedule for a Job or Process Flow:
1. Select the Schedule tab for a Job or Process Flow as shown below
 Applications Manager 9.4.1

2. Click New.
Applications Manager displays the schedule editing window shown below.
 Applications Manager 9.4.1

3. Complete the fields on the General and Frequency schedule sub-tabs. If necessary, you may also specify one
or more schedule exceptions on the Exceptions sub-tab, and/or override prompt values on the Prompts sub-
tab.
Details on completing each of these tabs is provided in the next topics.
Also, Example Schedules shows several example schedules.
4. To save the settings and add the schedule to the Job or Process Flow, click OK.
Applications Manager adds the schedule to the list at the top of the Schedule tab. The schedule will be
highlighted to show that it is selected for the Job or Process Flow.
Editing and Deleting Schedules
Selecting a schedule from the list will show its detail in the Schedule tabs. To edit a schedule, click Edit. To delete
a schedule, click Delete.

Entering General Information for Schedules

Use the schedule's General tab to name a schedule, set a start date and time and select execution options.
 Applications Manager 9.4.1

To set a schedule's general options, complete the fields using the information below.
• Name
The name of the schedule. Can be up to 30 characters.
• Frequency
Displays the frequency type and scheduled days selected on the Frequency sub-tab.
• Scheduled start date
The earliest date on which the Job/Process Flow is eligible to run.
• Scheduled end date
The latest date on which the Job/Process Flow is eligible to run.
• Start times
One or more start times, in 24 hour format (HH:MM), when the Job or Process Flow will be submitted. These
times do not indicate exact start times—system load and conditions can affect start times. You can enter as
many comma-separated start times as you wish. All start times must be in chronological order.
• Next run date
The next date Applications Manager will evaluate the schedule to see if it is eligible to run. When the Job or
Process Flow runs, Applications Manager updates this field based on the information in the other scheduling
fields. You can update this field by clicking the Calculate button.
When you stage a task, this value will be updated to the Job or Process Flow's next run. For more information
on staging, see chapter Scheduling Jobs and Process Flows.
• Queue
Identifies the Queue to which the Job or Process Flow will be submitted. When applied to a Process Flow, this
setting overrides the Queue setting for the Process Flow's components.
• Requestor
Indicates the User that the Job or Process Flow components will run under. You must have the Select
Requestors User Option assigned to you by your Applications Manager administrator to select a different User
in this field.
• Agent
For Jobs: Specifies the Agent for the Job, if it has an Agent Group selected in the Agent/Group field of the
Job's definition. The Agent selected in this field will be ignored if the Job is not assigned to an Agent Group that
includes this Agent. If 'No selection' is selected, the Job will run on the Agent/group selected in its definition.
 Applications Manager 9.4.1

For Process Flows: Specifies the Agent for all Jobs in this Process Flow that have an Agent Group selected in
the Agent/Group field of their Job definition. The Agent selected in this field will be ignored for any Jobs that are
not assigned to an Agent Group that includes this Agent. If 'No selection' is selected, the Jobs in this Process
Flow will run on the Agent/group selected in their Job definition.
For information on assigning Agents to Jobs, see Defining Jobs.
This setting can be overridden on the Submit window when requesting the Process Flow on an ad hoc basis.
OAE Jobs: You cannot change the Agent selection for OAE Jobs.
• Time zone
The time zone the schedule will run under. This field is only active if the time zone has been set for the
Automation Engine.
Select a standard time option if your computer does not adhere to daylight saving time. UTC refers to the
Universal Time Coordinate, which is used for the synchronization of computers on the Internet. If you do not
select a time zone, the Process Flow will run based on the Automation Engine's setting. For additional time zone
information, see the Administration Guide.
Warning: To assure that Jobs and Process Flows run at the correct time, make sure your OS and
database use the same time zones.
• Last submit time
This read-only field displays the date the Job or Process Flow last ran.
• Active
When selected, the Job or Process Flow will run on this schedule.

Entering Schedule Frequencies

Using the schedule's Frequency tab, you can select a unit of time, and options. The unit you select determines the
options that are available.
 Applications Manager 9.4.1

To set a schedule's frequency, select a unit of time from the Units box and its options on the Frequency sub-tab.
Unit descriptions and their details are listed below.
• Minutes/Hourly
• Enter a number of minutes or hours.
• Select the days of the week you wish to include.
• Enter the Run Between times. The task runs only between these times.
Applications Manager determines the task's initial start time based on the time specified in the Start times field
on the schedule's General tab.
• Daily
• Enter the number of days in the Every __ Days field. Applications Manager will schedule the task to run
every three days. If the task cannot run on the scheduled day, Applications Manager will run it on the next
available day.
• Select the days of the week you wish to include.
• Weekly
• Enter a number of weeks.
• Enter a date in the Reschedule from field. For a weekly schedule, this date determines the day of the week
to reschedule from. For example, if you enter 03-17-11, in the Reschedule from field, Applications Manager
will always reschedule from Thursday, since 03-17-11 is a Thursday. Keep in mind that an exception may
prohibit the schedule from running on the day of the week of your reschedule from date, when this happens,
the radio button you select in the Exception method box determines the schedule's behavior.
• Select the days of the week you wish to include.
• Select an Exception method. The Exception method box determines how Applications Manager will
handle days that are skipped by a skip Calendar or are included on the schedule's Exceptions tab. For more
information, see Setting Reschedule From and Exception Method Options.
• Monthly
• Enter a number of months.
• Enter a date in the Reschedule from field. For a monthly schedule, this date determines the day of the
month to reschedule from. For example, if you enter 03-17-11, in the Reschedule from field, Applications
Manager will always reschedule from the 17th day of the month. Keep in mind that an exception may prohibit
the schedule from running on the day of the month of your reschedule from date, when this happens, the
radio button you select in the Exception method box determines the schedule's behavior.
• Select Weekdays, Every day, or Selected days with the boxes checked for the days you wish to include.
• Select an Exception method. The Exception method box determines how Applications Manager will
handle days that are skipped by a skip Calendar or are included on the schedule's Exceptions tab. For more
information, see Setting Reschedule From and Exception Method Options.
When a schedule's frequency is Monthly, and the Next run date is the last day of the month, all following 'next
run dates' will be the last day of the month.
You can set the Next run date to a date greater than or equal to the 28th, but less than the last day of that
month. If you do so, when a month is reached that does not include that number of days (for example, the 30th
of February), the date will be set to the last day of that month. It will continue to be scheduled to the last day of
the month from that point forward.
• Workday
A special schedule used to identify a specific day of the month. For more information, see Creating Workday
Schedules.
• Fiscal
A special schedule used to build fiscal Calendars. For more information, see Creating Fiscal Calendar
Schedules.
• Calendar
Select a Calendar to run the Job or Process Flow on. Then select Weekdays, Every day, or Selected days
with the boxes checked for the days you wish to include.
Assigning Skip Calendars to Schedules
Skip Calendars are available for any schedule. They are used to specify days not to run, such as holidays, end of
month processing dates, and end of fiscal quarter processing dates. If you pick an Applications Manager Calendar
 Applications Manager 9.4.1

as a schedule's skip Calendar, Applications Manager will not run the Job or Process Flow on the dates it includes.
For information on defining Calendars, see Defining Calendars.

Setting Reschedule From and Exception Method Options

Use the Reschedule From option to avoid schedule creep. Use the Exception method options to determine
how Applications Manager handles days that are skipped by a skip Calendar or are included on the schedule's
Exceptions tab.

Avoiding Schedule Creep with the Reschedule From Option

After a Job or Process Flow using the Weekly or Monthly frequency runs, the values in the following fields are
evaluated to determine a new Next run date on the General tab:
• Every ___ Week for schedules with a Weekly frequency, or Every ___ Month for schedules with a Monthly
frequency
• The checkboxes for each day of the week
• The date in (dd:mm:yyyy) form in the Reschedule From field (displayed only when the Weekly and Monthly
options are selected)
The Reschedule From field is used to create schedules that run on days such as the first Friday after the 15th
of every month. If left blank, the Process Flow is rescheduled based on the day it ran, and you can get 'schedule
creep' where the value for the Next run date moves back or ahead several days each time the Process Flow runs.
For an example of how this option is used, see the example titled Run a Process Flow the First Wednesday After
the Fifteenth of Each Month at 11 P.M. in Example Schedules.
Determining How Applications Manager Handles Skipped Days
The Exception method group box is displayed when you select Weekly, Monthly, or Fiscal in the Units group
box The method you select determines how Applications Manager handles days that are skipped by a skip
Calendar or are included on the schedule's Exceptions tab.
 Applications Manager 9.4.1

The Exception method options are described below.

Option: The task will:

Next checked day Run the next checked day of the week. You might want
to use this setting if you have a Job or Process Flow
that runs once a week on Tuesdays, and you want it to
run on Thursdays if it is skipped.

Next weekday Run the next weekday, whether the Job or Process
Flow is scheduled that day or not.

Next day Run the next day, whether the Job or Process Flow is
scheduled that day or not. It does not matter if the next
day is a weekday or a weekend day.

Skip Not run.

Closest weekday Run on the closest weekday, whether the Job or

Process Flow is scheduled that day or not. The closest
weekday for any Friday is Thursday. For all other days,
it is the following day.

Prior day Run the previous day, whether the Job or Process Flow
is scheduled that day or not. It does not matter if the
previous day is a weekday or a weekend day.

Prior checked day Run the previous checked day of the week. You might
want to use this setting if you have a Job or Process
Flow that runs once a week on Thursdays, and you
want it to run on Tuesdays if it is skipped. To do this
you would check both Tuesday and Thursday, and use
the Reschedule From field to make sure the Job or
Process Flow usually runs on Thursday.

Prior weekday Run the previous weekday, whether the Job or Process
Flow is scheduled that day or not.

Creating Workday Schedules

Using workdays, you can create schedules based on a specific day measured from the beginning or the end of the
month. For example, you might want to run a task on the 5th working day of the month, or on the 4th workday from
the end of the month.
 Applications Manager 9.4.1

In the image above, the schedule will run SALES_REPORTS on the fourth Monday through Friday workday of each
month.
Procedure
To create a workday schedule:
1. On the Frequency tab, select Work Day from the Units group box
2. Enter a value in the ___ (st, nd, rd, th) Workday field.
The ___ (st, nd, rd, th) Workday field works differently than the field used for other schedule units. It runs once
a month based on this setting instead of every so many days.
If you need a Job or Process Flow to run on more than one workday in a month, you can create several workday
schedules for it. For example, if you wanted a Process Flow to run on the 5th and 20th workdays of each month,
you would create a workday schedule for the 5th and a second workday schedule for the 20th.
3. Select one of the following options: From the start of the month or Before the end of the month.
4. In the Workdays group box select the days of the week that will be considered work days.

Creating Fiscal Calendar Schedules

A fiscal Calendar is a span of 365 days (366 in leap years) during which the financial activities of an organization
are calculated. A fiscal year is divided into fiscal periods, typically defined as semesters, quarters, or months.
A fiscal Calendar can start on any day of the year. Fiscal Calendars result in more uniform accounting periods
throughout the year.
 Applications Manager 9.4.1

Examples
Fiscal Calendar schedules are useful for the following types of scenarios:
• Run task XYZ on the last Friday of each fiscal month.
• Run task XYZ on the second and fourth Friday of each fiscal month.
• Run task XYZ on the last Friday of each fiscal quarter. If Friday is a holiday, run the task on the prior workday.
• Run task XYZ on the last Friday of each fiscal month, except for the dates included in a Holiday skip Calendar.
On skip days, run the task on the prior weekday.
Fields
When you select Fiscal in the Units group box on the Frequency tab, Applications Manager displays the fields
shown in the image above. The fields are described below.
• Name
The Name field is used to select a fiscal Calendar. Fiscal Calendars are created by running the
CREATE_FISCAL_CALENDARS Job. When you define a fiscal Calendar, you determine its:
• start date
• fiscal Calendar type (445, 454, 544, 444)
• start day of week
For more information on creating fiscal Calendars, see Creating Fiscal Calendars.
• Run days
The run days specify the days of the week (Mo, Tu, We, etc.) that the task is eligible to run.
• Exception method
The Exception method box determines how Applications Manager will handle days that are skipped by a skip
Calendar or are included on the schedule's Exceptions tab. For more information, see Setting Reschedule
From and Exception Method Options.
 Applications Manager 9.4.1

• Period
The periods are the fiscal months. If the 444 fiscal Calendar is used, there will be a 13th period.
• Week
The cycles are the weeks in a month. If there is a fifth week, it is designated by the Last option. If you select
only the Last option, this designates the last week in the month, which will always be the forth or fifth week.
• Skip Calendar
Defines dates on which the task will not run.

Creating Fiscal Calendars

You create a fiscal Calendar by running the CREATE_FISCAL_CALENDAR Job shown below. When you define a
fiscal Calendar, you determine its:
• Start date.
• Fiscal Calendar type (445, 454, 544, 444).
• Start day of week.
 Applications Manager 9.4.1

The CREATE_FISCAL_CALENDAR Job includes the following prompts:

• fiscal Calendar name
The name you enter here will form the first part of the name which will be selectable from the Name field when
creating fiscal Calendar schedules.
• fiscal Calendar description
The name you enter here will form the second part of the name which will be selectable from the Name field
when creating fiscal Calendar schedules. It is a good idea to include a description of the values of the following
prompts. For example, '445-0103-Saturday' would be a good description. The name of the fiscal Calendar will
be <prompt 1>--<prompt 2>. For example, STATE--445-0103-Saturday. For more information, see Creating
Fiscal Calendar Schedules.
 Applications Manager 9.4.1

• start date of fiscal year

The day of the year that your fiscal Calendar starts, in MMDD format.
• fiscal Calendar type
The fiscal Calendar type (445, 454, 544, 444).
• fiscal week start
The day each fiscal week begins on.
Deleting Fiscal Calendars
To delete a fiscal Calendar, run the DELETE_FISCAL_CALENDAR Job. It includes one prompt where you can
select the fiscal Calendar you wish to delete from a list.

Entering Schedule Exceptions

Using a schedule's Exceptions tab, you can exclude a regularly scheduled running of a Job or Process Flow, or
include a new one.

Adding, Editing, and Deleting Exceptions from the Exceptions Tab

To add an exception to an existing schedule:
1. From the schedule's Exceptions tab, click New.
 Applications Manager 9.4.1

Applications Manager opens the Exceptions window.

2. On the Exceptions tab, enter the date of the exception (DD-MM-YYYY) in the Date field.
3. Enter a time (HH:MM) or select one from the drop-down list.
The times available for the drop-down list are based on the times entered in the Start times field on the
schedule's General tab.
4. Select the Exclude or Include radio button to determine whether you want Applications Manager to skip a run
for a regularly scheduled Job/Process Flow, or run once when not usually scheduled.
5. Click the OK button.
Applications Manager adds the exception to the table.
You can select defined exceptions and update or delete them using the appropriate button.
Adding and Removing Exceptions from the Schedule Display Window
You can also add exceptions by highlighting one or more schedules and selecting the Display button on the
Schedules tab. For more information, see Displaying Run Dates for Schedules.

Specifying Prompt Values for Schedules

There may be times when you wish to override the default value for one or more prompts when a Job or Process
Flow is called by a schedule. To do this, enter the new value in the Value column.
Prompts cannot be added, updated, or deleted from this tab.

This topic presents a brief discussion of prompts. For a detailed discussion of prompts, see chapter Adding
Prompts to Jobs and Process Flows.
The Prompts tab displays a table that lists the prompts defined on the Prompts tab of the Job or Process Flow.
The table includes the following columns:
• #: The order of the prompts in the Job or Process Flow.
• Default: The prompt value defined in the Job or Process Flow definition.
• Description: The description for the prompt defined in the Job or Process Flow definition.
• Value: You can edit in this column to override prompt values. If the prompt's data type allows you to select a
value, the Select button will be active. A value entered here will override the default value. Values allow the use
of static, dynamic and numeric Subvars. You can use multiple Subvars in the same value. When you do, be
sure to enclose them in { } braces. For example, {#1}{#2} or {#today}{#1}. You can select static and dynamic
Subvars using the { } button. To specify a null value for a Process Flow component's prompt that includes a
 Applications Manager 9.4.1

default value, enter two single quote characters. If you do not specify a prompt value, the component will use
the default prompt value.
• Required: Indicates whether a prompt value (in either the Default or Value column) is required. If a value is
required for one or more Process Flow component prompts, and you do not provide them, a message will pop
up asking you to provide values or ignore them.

Defining Calendars
Sometimes there are days when information is handled in special ways. In Applications Manager, you can specify
days by creating Calendars. You can schedule Jobs and Process Flows to run or not run on the days specified by a
Calendar. Calendars are useful for specifying a set of dates such as holidays, end of month processing dates, and
end of fiscal quarter processing dates.

Applications Manager User Groups control access to Calendars. If you do not have access to them, see your
Applications Manager administrator.
Procedure
To define a Calendar:
1. From the Calendars Selector window, click New.
 Applications Manager 9.4.1

Applications Manager opens the Calendars window shown above.

For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
2. Enter a name and description for the Calendar.
3. Do one or both of the following to add dates to your Calendar. These could be run or skip dates, depending on
the use of your Calendar:
• Click dates on the Calendar to select or deselect them. Use the arrow buttons to scroll by month and the
double arrow buttons to scroll by six month increments.
• Select the Date Builder tab to generate a list of days to add to or remove from the Calendar. For instructions
on using the Date Builder tab, see Generating Calendar Days from the Date Builder Tab.
Editing and Deleting Calendars
To edit or delete a Calendar, select the Calendar on the Calendars Selector window and select the appropriate
button. For information on using selector windows, see Adding, Editing, and Deleting Applications Manager
Objects.
If you edit a Calendar that is assigned to one or more Jobs or Process Flows, Applications Manager will display a
Calendar Usage window to show you these references when you click OK or Apply. You can view references for
a Calendar by selecting the Calendar's References tab, or by clicking the Usage button on the Calendar's selector
window.
Purging Past Calendar Dates
After selected days in Calendars have passed, you may not need Applications Manager to store them in the
database any longer. You can remove dates that have passed from all Applications Manager Calendars by
running the PURGE_CAL_DATES Job. The PURGE_CAL_DATES Job includes one prompt where you specify a
date before which to delete all days. The prompt value uses the format DD-MMM-YY. Its default prompt value is
determined by the #beginning_of_year Substitution Variables.

Generating Calendar Days from the Date Builder Tab

Days to include or exclude in an Applications Manager Calendar are usually selected by clicking dates on the
General tab of the Calendar. However, there may be times when you want to generate a list of dates for the
Calendar. Once you generate a list of dates you can click to select additional dates to add or remove. You can even
generate additional dates to include in or exclude from the same Calendar. You may want to generate a Calendar
when:
• Dates are not easily scheduled. For example, there are lots of exceptions or non-cyclic dates.
• You want to use the same set of dates to run a schedule and use as a skip Calendar and you only want to
define those dates once.
• You create Calendars to schedule cyclic tasks out of personal preference.
Procedure
To generate a list of days for an Applications Manager Calendar:
1. Select the Date Builder tab on the Calendars window as shown below.
 Applications Manager 9.4.1

2. Select a unit of time from the Units box and specify details.
Unit descriptions and their details are listed below.
• Daily
• Enter the number of days in the Every __ Days field. For example, if you enter 3, Applications Manager
will include every third date.
• Select the days of the week you wish to include.
• Weekly
• Enter a number of weeks.
• Enter a date in the Reschedule from field (see below).
• Select the days of the week you wish to include.
• Monthly
• Enter a number of months.
• Enter a date in the Reschedule from field (see below).
• Select Weekdays, Every day, or Selected days with the boxes checked for the days you wish to include.
• Workday
A special schedule for your Calendar used to identify a specific day of the month. For more information, see
Creating Workday Schedules.
• Fiscal
 Applications Manager 9.4.1

A special schedule for your Calendar used to build fiscal Calendars. For more information, see Creating
Fiscal Calendar Schedules.
• Calendar
Select another Calendar to generate days from. Then select Weekdays, Every day, or Selected days with
the boxes checked for the days you wish to include.
• Start Date
The earliest date on which the Calendar will include days.
• End Date
The latest date on which the Calendar will include days.
• Reschedule From
Used to create schedules that run on days such as the first Friday after the 15th of every month. If left blank,
the Process Flow is rescheduled based on the day it ran, and you can get schedule creep (when the value
for the Next run date moves back or ahead several days each time the Process Flow runs).
3. When you have selected a unit of time and its details, select one of the following:
• Create Dates adds the days to the Calendar.
• Remove Dates removes the days from the Calendar.
The General tab for the Calendar is updated with the changes you made.

Displaying Run Dates for Schedules

As you develop schedules, it may be helpful to see the run dates that would result from the schedule. You can do
this by clicking the Display button on the Schedule tab. Applications Manager displays the 12 Month Schedule
window shown above.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Selecting Schedules
If you have defined more than one schedule, you can choose to display the dates for any combination of the
schedules. To select one or more schedules, use the Shift+click and Ctrl+click keyboard/mouse combinations.
Viewing and Editing Days
Color codes for the 12 Month Schedule window are described below:

Days displayed with: Represent:

Gray backgrounds Single schedule days

Yellow backgrounds Multiple schedule days

Red numbers Exclude exception days

Green backgrounds Include exception days

Black numbers with white backgrounds Non-scheduled days

To change a single schedule day to an excluded day, or to change a non-scheduled day to an included exception
day, click that day. Double-clicking a day will change all eligible days in that day's week.
You cannot enter exceptions for a day if it is included in more than one schedule for the Job or Process Flow.
Printing the Run Date Calendar
Using the commands under the Print menu, you can set up the print page, preview the printed Calendar, and print
the Calendar.

Example Schedules
This topic shows example schedules that:
• Run a Process Flow on Monday, Wednesday, and Friday at 6 A.M.
• Run a Job Every Day, Except Holidays, at 9:30 P.M.
• Run a Job on Holidays Only, at 11:59 P.M. Eastern Standard Time .
• Run a Process Flow the First Wednesday After the Fifteenth of Each Month at 11 P.M.
• Run a Process Flow Monday, Wednesday, and Friday at 8 A.M., 9 A.M., 12 Noon, 5 P.M. and 11:45 P.M.
• Run a Process Flow on the First Day of each Fiscal Month .
• Run a Payroll Process Flow on the Fourth Workday from the End of the Month .
Some screen captures in this topic show sized down windows that do not show all fields. This is only done when
the fields that are not visible are not relevant to the example.
Run a Process Flow on Monday, Wednesday, and Friday at 6 A.M.
To run a Process Flow on Monday, Wednesday, and Friday at 6 A.M., you would use the settings shown above.
 Applications Manager 9.4.1

The time 06:00 is entered in the Start times field. Daily is selected as the Units. Monday, Wednesday, and Friday
are checked as eligible run days.
Run a Job Every Day, Except Holidays, at 9:30 P.M.
To run a Job every day, except holidays, at 9:30 P.M., you would use the settings shown below.
 Applications Manager 9.4.1

The time 21:30 is entered in the Start times field. Daily is selected as the Units. Every Day is selected, so that all
days of the week are checked as eligible run days. HOLIDAYS is designated in the Skip Calendar field.
Run a Job on Holidays Only, at 11:59 P.M. Eastern Standard Time
To run a Job on holidays only, at 11:59 P.M. Eastern Standard Time, you would use the settings shown below.
 Applications Manager 9.4.1

The time 23:59 is entered in the Start times field. The time zone EST {GMT -5} is selected in the Time Zone field.
Calendar is selected as the Units and the HOLIDAYS Calendar is selected in the Calendar field. Every Day is
selected so that all days of the week are checked as eligible run days.
Run a Process Flow the First Wednesday After the Fifteenth of Each Month at 11 P.M.
 Applications Manager 9.4.1

To run a Process Flow the first Wednesday after the fifteenth of each month at 11 P.M., you would use the settings
shown below.
Applications Manager 9.4.1
 Applications Manager 9.4.1

The time 23:00 is entered in the Start times field. Monthly is selected as the Units. Wednesday is the only day
checked as an eligible run day. 5-15-2009 is entered in the Reschedule From field.
Run a Process Flow Monday, Wednesday, and Friday at 8 A.M., 9 A.M., 12 Noon, 5 P.M. and 11:45 P.M.
To run a Process Flow Monday, Wednesday, and Friday at 8 A.M., 9 A.M., 12 Noon, 5 P.M. and 11:45 P.M., you
would use the settings shown below.
 Applications Manager 9.4.1

The times 08:00,09:00,12:00,17:00,23:45 are entered in the Start times field. Daily is selected as the Units.
Monday, Wednesday, and Friday are checked as eligible run days.
Run a Process Flow on the First Day of each Fiscal Month
To run a Process Flow on the first day of each fiscal month, you would use the settings shown below.

Fiscal is selected as the Units. The correct fiscal Calendar is selected from the Name field. Every day is selected
as a run day. All periods are checked. For Week, 1 is selected. Exception method only applies if a skip Calendar
is selected, or if a run date is selected on the Exceptions tab.
Run a Payroll Process Flow on the Fourth Workday from the End of the Month
To run a payroll Process Flow on the fourth workday from the end of the month, you would use the settings shown
below.
 Applications Manager 9.4.1

Workday is selected as the Units. The number 4 is entered in the ___ (nth) Workday field, and the From End of
Month option is selected. Weekdays is selected, so that Monday through Friday are checked as eligible run days.

Skipping Scheduled Tasks While the Automation Engine Is Stopped

If the Applications Manager Automation Engine is restarted after being stopped, either due to a system outage
or because it was intentionally stopped, it checks the value of the Next run date field in the schedule(s) of each
Job and Process Flow. The Automation Engine determines whether it should run each scheduled task. If a Job or
Process Flow was scheduled to run while the Automation Engine was stopped, that task will run immediately once
the Automation Engine is restarted. However, you may not want your tasks to run until their next scheduled run
time. You can keep these tasks from immediately running by selecting the Defer schedules on startup Automation
Engine option as shown below. All tasks that would have been submitted to the Automation Engine will be skipped
without being written to History.
 Applications Manager 9.4.1

Scheduling for Daylight Saving Time

Daylight saving time (DST), is the practice of advancing clocks during summer months so that evening daylight
lasts longer, while sacrificing normal sunrise times. Typically, regions that use daylight saving time adjust clocks
forward one hour close to the start of spring and adjust them backward in the fall to standard time.
Special circumstances for Applications Manager scheduling for spring and fall changes are described below.
The Spring Change
Clocks are set ahead one hour when DST starts. On that day, you lose an hour. The lost hour is considered invalid
time and schedules avoid that hour. The date and time DST starts varies in different countries.
Below is some information about the spring time change:
• Schedules with Minute schedule frequencies wait the number of minutes specified, regardless of the clock
change.
For example, assume a Job is scheduled every six minutes. It runs on schedule at 1:56. If in the spring, the time
changes from 1:59 to 3:00, the Job's next scheduled start time will be 3:02. Therefore, it would be scheduled
every six minutes 1:50, 1:56, 3:02, 3:08, etc.
• Schedules with Hourly schedule frequencies wait the number of hours specified, regardless of the clock
change.
For example, assume a Job is scheduled every two hours minutes. It runs on schedule at 11:30. If in the spring,
the time changes from 1:59 to 3:00, the Job's next scheduled start time will be 2:30. Therefore, it would be
scheduled every two hours 9:30, 11:30, 2:30, 4:30, etc.
• If schedule frequencies are Daily or greater and they are scheduled in the lost hour, they will become eligible to
run at the top of the hour.
 Applications Manager 9.4.1

For example, assume a Job is scheduled daily at 2:20. If in the spring, if the time changes from 1:59 to 3:00, the
Job's next scheduled start time will be 3:00. The next day, it will be 2:20 again.
Be Aware of the Max Run Time Setting During the Spring Change
If you have done both of the following for one or more Jobs, those tasks will abort during the spring time change:
• Selected a Max run time of less than one hour in the Job definition.
• Scheduled the task to run during the daylight saving time transition.
If this happens, you can resubmit the task to run it to completion.
Evaluating Time-Relevant Conditions During the Spring Change
The conditions that reference time behave according to the time that the condition is executed. For example, if
a condition with a DELAY TASK action executes at 1:59 and delays for 5 minutes before the time change, the
condition will be evaluated again in 1 minute. The reason for this is that as soon as the hour ends, it becomes 3:00
and the action is eligible to be taken immediately.
The Fall Change
In the fall, clocks are set back one hour when DST ends. On that day, you gain an hour. The date and time
DST starts varies in different countries.
Below is some information about the fall time change:
• When the time zone of the Automation Engine exits DTS, all the Jobs, regardless of their Time Zone setting, will
not run for the repeated hour.
• Jobs and Process Flows scheduled to run during the transition time will not run twice.
• Whether a Job or Process Flow scheduled to run during the transition time runs in the first or repeated hour
depends on whether it is scheduled to run on the same time zone as the Automation Engine.

When the scheduled to run: It runs:

Without a time zone specified In the first hour using the Automation Engine's time
zone
With a time zone specified In the repeated hour

Evaluating Time-Relevant Conditions During the Fall Change

The conditions that reference time behave according to the time that the condition is executed. For example, if in
the fall, the time changes from 1:59 to 3:00 and a condition with a DELAY TASK action executes at 1:59 and delays
for 5 minutes before the time change, the task will execute at 2:05. This will be one hour and 5 minutes later.

Exporting and Importing Objects

When you want to move Applications Manager objects from one system to another, you use the Applications
Manager Export and Import features. When importing, you can map any objects, including objects that were not
exported. You can save the map file and use it for other imports.
Warning: You cannot import between versions of Applications Manager (such as from 8.0 to 9.2). Doing so
is wholly unsupported by Broadcom and can lead to serious version conflicts.

Most corporations maintain separate development, test, and production instances. These instances can be local
(residing on the same host) or remote. When you are ready to move Applications Manager objects from one
instance to another, you can use the Applications Manager Export and Import features.
Applications Manager 9.4.1
 Applications Manager 9.4.1

You can export all Applications Manager objects except Agents, Agent Groups, Logins, and Users. These objects
must exist or be created on the target system.
When you export, you select Jobs, Process Flows, and support objects (the objects that are referenced by the Jobs
and Process Flows you select) that can be transferred from one instance to another. The export produces an .exp
file.
When you import, all objects in the .exp file must be one of the following:
• Included in the import.
• Mapped to an object with the same name in the target instance.
• Mapped to an object with a different name in the target instance.
• Created in the target instance.
With this functionality, Jobs, Data Types, User Groups, and other objects can be developed in one instance and
transferred throughout the Applications Manager environment. The source instance(s) (development and/or QA)
contain objects that will be used in one or more additional instances.
In many cases, the objects on the development system will be different than on a test or production system. For
example, an Output Device called DEV1 on the development machine may be replaced by TEST1 on the test
machine and PROD1 on the production machine. To accommodate the different support objects, you can map
objects when importing.
An initial export and import may require some effort to create the appropriate map. However, you can save the map
and use it each time you perform an export-import between the same two machines. Subsequent export-imports
may require few if any updates to the map.
In order to run exports and imports, users need to have the Export and Import User Authorities and the IMPEXP
Job assigned to their User Group(s).
The key steps for importing and exporting are described in Export/Import Flowchart.
Exports Do Not Include Scripts
When you export Jobs, Program Types, or Output Interfaces, you are exporting the Applications Manager object
only. If the accompanying script does not exist on the target system, you will need to FTP it over.
Single vs. Multiple Exports/Imports
The Applications Manager Import/Export utilities provide flexibility when it comes to managing objects. In some
cases, it may be practical to export only one object type at a time. In other cases it may be practical to export a
group of objects. These are organization-specific decisions.
Auditing Imports
To make sure you don't overwrite any object definitions by accident, you can turn on import auditing and run the
import. You can see all potential changes by viewing a report named AW_IMPORT_AUDIT. To accept the changes,
you simply run the import again without import auditing enabled. To run audit imports, auditing must be enabled for
the Automation Engine.
Copying Applications Manager Instances
The Applications Manager export and import utilities are designed to move Applications Manager objects. If
you want to move or copy an entire Applications Manager instance, you should use your database utilities. For
information on moving and copying Applications Manager instances, see chapter the Administration Guide.
Importing Objects with Multi Data Types Prompts that Select Applications Manager Objects
When you export and import objects that use Multi Data Types that reference AM objects, only the objects that exist
on the target instance will be referenced after the import. Note that the reference numbers will be different on the
target instance than they were on the source instance.
Exporting and Importing Process Flows with Predecessors Between Components in Nested Process Flows
You can create internal predecessors between components in nested Process Flows, but they will not export/import
to another Applications Manager instance. To work around this, you can either manually recreate the predecessors
on the target instance, or define External predecessors in the nested Process Flow definitions.

Export/Import Flowchart
The key steps in the export/import process are presented below and illustrated in the flowchart below:
• On the source instance, do the following:
 Applications Manager 9.4.1

• Select the Jobs and Process Flows you wish to export.

• Add the support objects for the Jobs and Process Flows with the References tab.
• If you are doing a repetitive export, save the export list.
• Run the export. This creates an .exp file in the export directory under AW_HOME.
• FTP or copy the .exp file to the import directory under AW_HOME on the target system.
• On the target instance, do the following:
• Load the .exp file by going to the File menu and selecting Open Import.
• Map objects and/or select a saved map.
If any support objects are missing from the map, re-import, or create them on the target instance.
• If you are doing a repetitive import, save your map file.
• Import.
Jobs and Process Flows should not be edited while running the STAGING Job or executing exports and imports.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Export/Import Terms
The following terms are used in this guide when discussing exports and imports.
Export file: An .exp file which is created when an 'export list' is exported. Export files are written to the export
directory on the source instance.
Export list: The list of objects you select from the Export window. The objects in the export list are displayed on
the Objects to be exported tab. As you build an export list, Applications Manager determines the 'referenced
objects'. Export lists can be saved at any time. Export files are saved to the export directory and have a .dat
extension.
Import file: An 'export file' which has been copied or transferred from the export directory on the source instance
to the import directory on the target instance.
Map: A matching of imported objects to existing objects on a target system. Maps can be made on the Import or
Map File tab of the Import window.
Map file: A list of 'mapped' objects used when importing. The mapped objects are displayed on the Map File tab
when importing. Map files can be saved at any time. Map files are located in the map directory and have a .dat
extension.
Referenced objects: Unselected objects that are assigned to the objects you select when building an export list.
When exporting, you can select the References tab to view and add reference objects. Agents, Agent Groups,
Logins, and Users are displayed as referenced objects, but cannot be added to the export list. These objects must
exist or be created on the target instance.
Support objects: Objects that are assigned to the Jobs and Process Flows you select when building an export list.

Building Export Lists

You can export objects with the Export window shown below. You can export all objects except Agents, Agent
Groups, Logins, and Users.
 Applications Manager 9.4.1

The Export feature may not be available to you. If you need to use it, see your Applications Manager administrator.
As you build a list of export objects, Applications Manager determines the support objects (such as Data Types,
Output Devices, Logins, and User Groups) that must be present on the target system to run the Jobs and Process
Flows. You can review these items on the References tab and add them to the export list. Export lists can be
saved at any time.
Procedure
To select objects to export:
1. Open the Export window by doing one of the following:
• Open the Activities menu and select Export.
• Select the Export icon from the toolbar.
2. Choose the type of object you wish to export.
Applications Manager displays all objects of the selected type on the Objects tab. In the image above, Jobs is
selected, displaying all Job objects.
3. Move objects to the Objects to be exported tab (or back).
Warning: If an imported object does not exist on the target instance, it is added to the target instance's
database. Objects that already exist are overwritten. You do not get a warning message.

Exportable Objects
All objects can be exported except Agents, Agent Groups, Logins, and Users. You must uniquely specify any
object(s) to be exported. For example, if you export Jobs or Process Flows that use Substitution Variables, the
variables will not automatically be exported. You must export Substitution Variables explicitly as their own objects.
 Applications Manager 9.4.1

When you export User Groups, only the User Group definitions are exported. Applications Manager does not
include the references to objects that have that User Group assigned to them.
Warning: Do not export the DBA User Group. Doing so will cause errors.

When you import, Applications Manager displays the referenced objects that are not included in the export. The
referenced objects can be:
• Included in the import.
• Mapped to an object with the same name in the target instance.
• Mapped to an object with a different name in the target instance.
• Created in the target instance.
Exporting Process Flow Components
Prompt override values for one or more Process Flow components can get attributed to the wrong prompt if you
import a Process Flow without also importing the Jobs it references as components.
When you are defining an export, you have the option to include the Jobs (and possibly other Process Flows) that
are components in the Process Flow. The reason Applications Manager doesn't automatically import all Jobs in
a Process Flow when the Process Flow itself is imported is so you won't overwrite a Job definition on the target
instance unless you intend to import it as well.
Reviewing References
As you add objects to the list, you can get a list of the referenced objects required by selecting the References tab
shown below. Use the arrow buttons to add these objects to the Objects to be exported tab. You can refresh the
Reference tab by going to the References menu and selecting Refresh.
 Applications Manager 9.4.1

Next Step
After building your export list, you run the export. If you are doing a repetitive export you will want to save it first.
These actions are described in Saving Export Lists and Exporting Objects.

Saving Export Lists and Exporting Objects

If you are doing a repetitive export, an export where you have selected objects that you will export multiple times,
you will want to save your export list to use again. It is recommended that you save your export list immediately
before running a repetitive export. If you are doing a one-time export there is no need to save the export list before
exporting.

Saving Export Lists

To save an export list:
1. Go to the File menu and select Save.
Applications Manager displays the Save export selection window shown above.
2. Enter a file name and click OK.
The name may be up to 30 characters long. Applications Manager stores the export list file in the export
directory under AW_HOME with a .dat extension.
The export list (.dat) file saves the names of the selected objects but not the elements that are contained
in the object. Export lists are convenient when performing repetitive exports, generally common early in the
development and testing phases. Instead of continually recreating your export list every time you want to export
an object, (or in most cases, a variety of objects), use the save command to save your updates. We recommend
using a naming convention that reflects its contents (for example, APP_Daily, or End_of_Month).
 Applications Manager 9.4.1

You can open an export list by going to the File menu and selecting Open.
Exporting Lists
To export a list of objects:
1. Click the Export button.
Applications Manager displays the Save Export File window shown below. If you have saved the export file,
that name will be displayed in the Name field.

2. Enter a valid file name and click OK.

The Export utility runs the IMPEXP Job under the alias EXPORT. When the Job completes executing, it writes
the file to the export directory under AW_HOME with an .exp extension. You can view the output file from
History.
Moving the Export File to the Target Instance
Before you can perform an import, you must FTP/copy the export (.exp) file to the import directory under the
AW_HOME directory on the target machine. It is an ASCII file, so you must use an ASCII FTP. When you move the
export file to the import directory, it is referred to as an import file. They are the same file.
Next Step
Once you export and move the .exp file, you are ready to open the import file and map the objects. These actions
are described in Opening Imports and Mapping Objects.

Opening Imports and Mapping Objects

To import objects, go to the Activities menu and select Import. To open an import file, go to the File menu and
choose Open Import File. You can map objects from the source system to objects on the target system. When you
import objects, all mapped objects (for example: Queues, Output Devices) must exist on the target machine.
Warning: You cannot import between versions of Applications Manager (such as from 8.0 to 9.2). Doing so
is wholly unsupported by Applications Manager and can lead to serious version conflicts.

After creating the export file on the source instance and moving it to the target instance, you are ready to import the
file. When you import, Applications Manager displays the objects referenced in the import that were not included in
the export.
The Import window is shown below.
 Applications Manager 9.4.1

The referenced objects must be handled in one of the following ways:

• Included in the import.
• Mapped to an object with the same name in the target instance.
• Mapped to an object with a different name in the target instance.
• Created in the target instance.
The Import feature may not be available to you. If you need to use it, see your Applications Manager administrator.
Warning: If an imported object does not exist on the target instance, it is added to the target instance's
database. Objects that already exist are overwritten. You do not get a warning message.

Procedure
To select an import file and assign a map:
1. Before importing data, make sure no one is working in Applications Manager and that no tasks are being
processed.
2. Open the Import window by doing one of the following:
• Open the Activities menu and select Import.
• Select the Import icon from the toolbar.
3. From the Import window, open the File menu and choose Open Import File.
Applications Manager opens the Files window shown below.
 Applications Manager 9.4.1

In the Export utility, you created an .exp file in the export directory. When you move the file to the import
directory on the target machine, it is referred to as an import file. They are the same file.
4. Select a file and click OK.
When you open an import file, Applications Manager looks for matching resources in the target database. If
it finds a matching resource, it displays an entry in the map column for the object. If it doesn't find a matching
resource, it leaves the entry blank. In the first image in this topic, TASK_TITLE is not mapped.
5. If you want to use a map file that you have saved, open it by going to the File menu and selecting Open Map.
If you had the map file open before opening the import file, you must select Apply Map File from the Edit
menu to use it.
6. For each of the unmapped items, select an object from the list box in the map column.
All objects must be mapped before you can import. If a support object does not exist, you can create it on the
target instance. All objects you map are shown on the Map File tab, and will be saved when you save the map
file. For information on the Map File tab, see Adding, Editing, and Deleting Map File Entries.
7. Select new values from the MAP column for any objects you wish to reassign.
You may wish to reassign the default mappings between instances. For example, you may have defined
Queue TEST1 on the source machine. On the target machine, you may want Queue TEST1 reassigned to
Queue PROD1. You can use a map to specify the change. Jobs and Process Flows cannot be reassigned, by
default they have the same name on the source and target machines. All objects you map are shown on the
Map File tab, and will be saved when you save the map file. For information on the Map File tab, see Adding,
Editing, and Deleting Map File Entries.
8. If you want to save the map file, click the Save Map File box and enter a name in the Map File field.
Map files are located in the map directory and have a .dat extension.
9. If you wish to audit the import, check the Audit Changes Only box. For more information on import audits, see
Performing Import Audits.
10. To import the file after all objects have valid destination names, select the Import button.
The Import utility runs the IMPEXP Job under the alias IMPORT. You can check the status of the Job from
the Explorer window. The Job creates a log called IMPORT.log. You can view the log with the File Viewer
window.
The newly imported objects will show up approximately five minutes after the IMPORT Job runs. If you want to
see them sooner, go to the View menu and select Refresh Assigned Objects or click the Refresh button on any
object's selector window.

Performing Import Audits

To make sure you don't overwrite any object definitions by accident, you can audit the changes an import will
make by running the import and checking the Audit Changes Only box You can then see the potential changes
by viewing a report named AW_IMPORT_AUDIT. To accept the changes, simply run the import again without the
Audit Changes Only box checked.
 Applications Manager 9.4.1

The person who creates an export on an Applications Manager source instance isn't always the one who runs the
import on the target instance. An unfortunate affect of this can be accidentally overwriting object definitions that
should not be touched.

The Import window includes the Audit Changes Only box shown above. When you check this box and run an
import, and the IMPORT Job (alias for IMPEXP) runs, it:
• Passes a prompt value that creates a report named AW_IMPORT_AUDIT detailing everything that is inserted
and deleted by the import.
• Writes text to the system output file that triggers an Output Scan to change the IMPORT task's status to AUDIT
ONLY.
• Rolls back all changes made by the import.
Prerequisite
To run audit imports, you must have the Enable Auditing box on the Audit tab checked for the Automation Engine
as shown below.
 Applications Manager 9.4.1

Viewing the AW_IMPORT_AUDIT Report

To view the AW_IMPORT_AUDIT report, click the Reports button on the Import window. From the Reports
window select the report and click Show. A sample AW_IMPORT_AUDIT report is shown below.

If you approve the changes, simply re-run the import without the Audit Changes Only box checked.

Adding, Editing, and Deleting Map File Entries

The Map File tab shown below includes a table of mapped objects.
 Applications Manager 9.4.1

You can save and open a map file using the Edit menu. When you save a map file, it is the items on the Map File
tab that are saved. The table includes:
• Objects that have been mapped on the Import tab.
• Objects that have been added using the Object Details box.
The map table can contain support objects that exist in both databases, but this is optional. The table does not
contain Jobs or Process Flows.
Maps are independent from import files and can be edited and saved without affecting them. Changes you make on
the Map File tab will be immediately reflected on the Import tab. The mappings do not alter the import file, but are
applied to it during the import process.
Adding Additional Map Entries
There may be times when you want to add an entry to a map file that was not included in the import file. You might
do this when objects do not exist at the time of the import, but will exist the next time you use the map file.
To add an entry:
1. In the Object Details box, select an object type from the Type list box
2. Enter the name of the object as you expect it to appear during an import.
3. Select the object on the target instance you want to map it to from the Map list box
4. Click Add.
Applications Manager adds the entry to the table and to the Import tab.
Updating Entries
To edit an entry:
1. Highlight the entry in the table that you wish to update.
Applications Manager displays the values for the entry in the Object Details box fields.
2. Edit the values of the fields and click Update.
 Applications Manager 9.4.1

Applications Manager updates the entry in the table and on the Import tab.
Deleting Entries
To delete an entry:
1. Highlight the entry in the table that you wish to delete.
Applications Manager displays the values for the entry in the Object Details box fields.
2. Click Delete.
Applications Manager removes the entry from the table. If the entry was included in the import file, it will map
to its default value on the Import tab. If the entry was not included in the import file, it will be removed from the
Import tab.

Example: Exporting a Job to Another Applications Manager Instance

Below is an example of how a User can export and import objects between Applications Manager instances.
Developer Pat Brown has created the EMP_DEPT_JOB Job shown below in the development instance and wants
to export it to the test instance. Keep in mind that the Job uses support objects such as the BATCH Library and the
AWSQLP Program Type.

To complete the export/import, Pat takes the following steps:

1. Using the Export feature, Pat starts building the export list by selecting the Job as shown below.
Notice that Pat used the Search field to find the EMP_DEPT_JOB Job. Good Job Pat!
 Applications Manager 9.4.1

When Pat adds the Job, the label for the References tab shows the references icon, indicating that the Job
includes support objects.
2. Pat selects the References tab, and sees two Data Types created for the Job, Job_Title and Dept_Name, and
adds them to the export list. Pat doesn't need to add support objects that are the same on the development and
production instances.
 Applications Manager 9.4.1

3. To save the export file, Pat goes to the File menu and selects Save as, then enters EMP_MOD1. Applications
Manager saves the file EMP_MOD1.dat in the export directory of the development instance. Using the Export
utility, Pat can open the export list at a later time.

4. To export the file, Pat selects the Export button and is prompted to select a name for the export file. Pat can
export the file using the same or a different name than the export list. Pat uses the same name. Applications
Manager saves the EMP_MOD1.exp file in the export directory of the development instance and runs the
EXPORT Job in the Backlog.
5. Pat switches to the Explorer window to monitor the export Job and make sure it finishes.
 Applications Manager 9.4.1

6. Pat transfers the export (.exp) file to the import directory on the target machine. Once the file is moved, it is
referred to as an import file. They are the same file.
7. Pat logs on to the target production instance and opens the Import utility. From the Import window, Pat opens
the File menu, selects Open Import File, and selects EMP_MOD1.exp file.

Applications Manager automatically maps the referenced objects. If a referenced object did not exist in the new
instance, Applications Manager would leave the object unmapped.
8. Pat accepts the default mappings and selects the Import button at the bottom of the window to import the file.
Applications Manager runs the IMPORT Job in the Backlog.
9. Next, Pat switches to the Explorer window to see that the Job has finished.

The Job and Data Types are now included on the production instance.

File Transferring
Applications Manager includes the following three FTP Jobs that prompt you for all the values required to transfer a
file between two networked machines:
• FTP_JAVA: This is an updated version of the FTP Job. It includes several prompts and prompt options not
available on the original FTP Job, such as mget and mput commands.
• SFTP_JAVA: This Job uses secure FTP with SSH to transfer files.
• FTP: This Job is the original Applications Manager FTP Job. It still works for customers who have upgraded or
wish to use a .netrc file to connect to a remote machine.
 Applications Manager 9.4.1

FTP, FTP_JAVA, and SFTP_JAVA are legacy Jobs with limited functionality. For the latest full featured FTP Jobs,
use the RA FTP Agent Jobs.
Defining Host Logins
The scripts supporting the FTP_JAVA, SFTP_JAVA, and FTP Jobs use an Applications Manager Host Login to hold
the machine name, Login name, and password for the destination machine. To use a Login, you must first define it.
Running the LOADER Job
Use the LOADER Job to run Oracle's SQL*Loader program for loading data into a database. The Job often follows
the FTP Job in an Applications Manager Process Flow.
The LOADER Job as well as the AWLOADP Program Type that used to be installed with new installs are now
included in the LOADER.exp import file.

FTP_JAVA Job
The FTP_JAVA Job prompts you for all the values required to transfer a file between two networked machines. It
contains additional commands and prompts not found in the original FTP Job that can be used to manipulate files
and directories.
FTP, FTP_JAVA, and SFTP_JAVA are legacy Jobs with limited functionality. For the latest full featured FTP Jobs,
use the RA FTP Agent Jobs.
FTP_JAVA Job performs file transfers between two networked machines. The Job with example prompts is shown
below. The output from the Job is automatically scanned to ensure the transfer completed successfully.
 Applications Manager 9.4.1

FTP_JAVA Prompts
The FTP_JAVA Job includes the following prompts shown above. The prompts are described below.
• Remote Machine UserId
The Host Login for the remote machine. Defining a Host Login is described in Defining Host Logins.
 Applications Manager 9.4.1

The FTP_JAVA Job requires a Host Login. If you need to use a .netrc file to connect to a remote machine, use
the FTP Job.
• Remote Machine HostName or IP
The host name of the remote machine on which to issue the command. The Agent running the FTP Job is the
local machine. This entry must match the host IP for the Host Login in the Remote Machine UserId prompt.
• Command
The command issued for the FTP. Options include:
• Append: Appends the local file to the remote file.
• Rename: Renames a file on the remote machine.
• Delete: Deletes a file on the remote machine.
• Get: Copies one file from the remote machine to the local machine.
• Put: Copies one file from the local machine to the remote machine.
• Mget: Copies multiple files from the remote machine to the local machine.
• Mput: Copies multiple files from the local machine to the remote machine.
• Other: Performs only the commands for additional FTP prompts as described below. When 'Other' is
selected, values must still be entered for all required prompt values, even when they are not used.
• Local Path
The path to the file on the local machine. The path must include the closing delimiter (slash, backslash, or
bracket, depending on your OS).
• Local File or Pattern
The file(s) or pattern for the files on the local machine.
• Remote Path
The path to the file on the remote machine. The path must include the closing delimiter (slash, backslash, or
bracket, depending on your OS).
• Remote File or Pattern
The file(s) or pattern for the files on the remote machine.
• File type
The protocol you select for the file type:
• Binary
• ASCII
Adding Prompts for Additional FTP Commands
You can add prompts to include additional FTP commands to the FTP_JAVA Job. If 'Other' is selected as the FTP
command, these will be the only commands taken. In any other case, these prompts will be executed before the
command selected for the 'Command' prompt.
Additional prompts must contain all arguments to the command, for instance:

put <local file spec.> <remote file spec.>

site quote lrecl=80

Accepted commands are as follows:

• GET - get a file from a remote machine
• PUT - put a file to a remote machine
• MGET - get multiple files from a remote machine
• MPUT - put multiple files to a remote machine
• APPEND - append a local file to a remote file
• DELETE - delete a file on a remote machine
• RENAME - rename a file on a remote machine
The commands are not case sensitive.
Creating Custom Versions of FTP Jobs
 Applications Manager 9.4.1

Usually FTP_JAVA and SFTP_JAVA Jobs are used in Process Flows where you set the prompt values for
their components. However, you may want to run them as stand alone Jobs. In this case, you can copy the
FTP_JAVA or SFTP_JAVA Job to a new name and edit the prompts of the new Job.

SFTP_JAVA Job
The SFTP_JAVA Job uses secure FTP with SSH to transfer files.
FTP, FTP_JAVA, and SFTP_JAVA are legacy Jobs with limited functionality. For the latest full featured FTP Jobs,
use the RA FTP Agent Jobs.
The SFTP_JAVA Job performs file transfers using secure FTP with SSH to transfer files between two networked
machines. For more information on setting up SSH Shared Keys, see topic the Administration Guide.
The Job with example prompts is shown below. The output from the task is automatically scanned to ensure the
transfer completed successfully.

SFTP_JAVA Prompts
The SFTP_JAVA Job includes the following prompts shown above. The prompts are described below.
• Remote Machine UserId
The Host Login for the remote machine. Defining a Host Login is described in Defining Host Logins.
• Remote Machine HostName or IP
The host name of the remote machine on which to issue the command. The Agent running the FTP Job is the
local machine. This entry must match the host IP for the Host Login in the Remote Machine UserId prompt.
• Command
The command issued for the FTP. Options include:
• Get: Gets one or more files
• Get-append: Gets and appends one or more files
• Put: Puts one or more files
• Put-append: Puts and appends one or more files
• Rm: Removes one or more files
• Rmdir: Removes a directory
• Mkdir: Creates a directory
• Local Path
The path to the file on the local machine. The path must include the closing delimiter (slash, backslash, or
bracket, depending on your OS).
• Local File or Pattern
The file(s) or pattern for the files on the local machine.
• Remote Path
The path to the file on the remote machine. The path must include the closing delimiter (slash, backslash, or
bracket, depending on your OS).
• Remote File or Pattern
The file(s) or pattern for the files on the remote machine.
• File type
The protocol you select for the file type:
• Binary
• ASCII
• Compress
No compression is the default.
Creating Custom Versions of FTP Jobs
Usually FTP_JAVA and SFTP_JAVA Jobs are used in Process Flows where you set the prompt values for
their components. However, you may want to run them as stand alone Jobs. In this case, you can copy the
FTP_JAVA or SFTP_JAVA Job to a new name and edit the prompts of the new Job.
 Applications Manager 9.4.1

FTP Job
Applications Manager includes an FTP Job that prompts you for all the values required to transfer a file between
two networked machines. The FTP_JAVA Job ships with Applications Manager. It includes several prompts and
options not included in this Job such as mputs and mgets.
FTP, FTP_JAVA, and SFTP_JAVA are legacy Jobs with limited functionality. For the latest full featured FTP Jobs,
use the RA FTP Agent Jobs.
The FTP Job performs file transfers between two networked machines. The Job with example prompts is shown
below. The output from the Job is automatically scanned to ensure the transfer completed successfully.
 Applications Manager 9.4.1

FTP Prompts
The FTP Job includes the seven prompts shown above. The seven prompts are described below.
• Destination Machine Name
The host name of the remote machine on which to 'put' the file or from which to 'get' the file. The machine
running the FTP Job is the local machine. When using a Host Login, this entry must match the host IP entry for
the login.
• Fully Pathed Local File
The fully pathed name for the file as it exists or will exist on the local machine.
• Fully Path Remote Machine
The fully pathed name for the file as it will exist or exists on the destination (remote) machine.
• Userid for Remote Machine
The OS login name for the remote machine.
• Fully Pathed Netrc Filename
When using an Applications Manager Login instead of a .netrc file (recommended), use 'dblogin' for the entry.
When using a .netrc file, enter the full path (including name) to the .netrc file that contains the connection
information for the remote machine.
• Transfer Mode ASCII/Binary
The mode to use for the transfer: ASCII or binary.
• Direction Get/Put
The direction for the transfer. 'Put' will transfer the file from the local machine to the remote machine. 'Get' will
transfer the file from the remote machine to the local machine.
FTP Host Login
The FTP.SH script supporting the FTP Job uses an Applications Manager Login to hold the machine name, login
name, and password for the destination machine. To use a Host Login with the FTP Job, you must define a Host
Login and assign it as the primary Login for the FTP Job as shown below. Defining a Host Login is described in
Defining Host Logins.
 Applications Manager 9.4.1

Using a Netrc File

You can use a .netrc file to hold the machine name, login name, and password instead of a Host Login for the FTP
Job (you cannot use a .netrc file with the FTP_JAVA or SFTP_JAVA Jobs). This has been standard practice in
many IT shops, but it does create a potential security risk. If someone can get access to the .netrc file, they can
obtain the logins to all of your host machines. The Applications Manager Login feature was created to safeguard
the login information.
Format
If you choose to use a .netrc file, it must conform to the following format.
Format:

machine <machine name> login <login name> password <password>

 Applications Manager 9.4.1

Example:

machine hp1 login jsmith password sesame

The .netrc file may contain entries for more than one machine or login.
After creating the .netrc file, change the access on the file to Owner Read/Write only by issuing the chmod
600 .netrc command.
After creating the .netrc file, add the FTP Job to a Process Flow and fill in the prompt values appropriately for the
file you want to transfer. Because you are using a .netrc file, fill in the Fully Pathed Netrc File prompt. Also, ensure
that no Login is specified for the Job. An example set of prompts is shown below.

Prompt Value

01 Destination Machine Name hp1

02 Fully Pathed Local File $AW_HOME/out/b.115

03 Fully Path Remote Filename /hp1/output/b.115

04 Userid for Remote Machine jsmith

05 Fully Pathed Netrc Filename $AW_HOME/exec/.netrc

06 Transfer Mode Ascii/Binary Ascii File Transfer

07 Direction Get/Put Put to Remote

An example Job showing the prompts is shown below.

 Applications Manager 9.4.1

Communicating with a Mainframe Using the FTP Job

There may be times when you need to FTP files to a mainframe. To do this, simply add prompts to the FTP Job.
Any data entered in these prompts will be sent before the Get or Put command selected in the Direction prompt. If
Other is selected for the Direction prompt, no Get/Put command will be sent.
If you add prompts to the FTP Job, they will not be overwritten when you upgrade Applications Manager.
Order of Commands Sent to the Remote Host
Regardless of the order of prompts in the FTP Job, the order of commands sent to the remote host is as follows:
 Applications Manager 9.4.1

1. open Host
2. verbose
3. prompt
4. direction type, Ascii or Binary
5. additional prompt values after Direction
6. Get or Put (or no value for Other)
7. quit
Sample Output for Sending a jcl File to JES
In this example, an additional prompt with the value quote site filetype=jes has been added to the FTP Job:

parameter file
200.1.1.229
$AW_HOME/jcl/job.jcl
job.jcl
adcdmst
$SQLOPER_HOME/.netrc
ascii
put
quote site filetype=jes

Sample Output for Sending a File to the Mainframe Using the FTP Job
In this example, four additional prompts with the values quote site blksize=6192200, quote site recfm=vba,
quote site recfm=fb, and quote site lrecl=80200 have been added to the FTP Job:

parameter file
200.1.1.229
$AW_HOME/data/net_conn.dat
testfile
adcdmst
$SQLOPER_HOME/.netrc
ascii
put
quote site blksize=6192200
quote site recfm=vba
quote site recfm=fb
quote site lrecl=80200
End of parameter file
job pid 27839

Defining Host Logins

The scripts supporting the FTP_JAVA, SFTP_JAVA, and FTP Jobs use an Applications Manager Host Login to hold
the machine name, login name, and password for the destination machine. To use a Login, you must define the
Login as shown below.
 Applications Manager 9.4.1

You will need separate Logins for each different login/machine combination you want to use with the FTP_JAVA,
SFTP_JAVA, and FTP Jobs. If the same Login name is needed on multiple machines, append a unique identifier to
the end of the Login name prefaced by an '@' (e.g.: am@sun2).
For Rapid Automation Agent documentation including Agent-specific Login object tabs, see the the following.
• The Banner Rapid Automation Agent for Local Clients Documentation
• The Banner Rapid Automation Agent for the Automic Web Interface Documentation
• All other Rapid Automation Documentation
Procedure
To create a Host Login:
1. From the Logins Selector window, click New.
For information on using selector windows, see topic Adding, Editing, and Deleting Applications Manager
Objects.
Applications Manager opens the Select Login Type window shown above.
2. Select the HOST Login type and click OK.
The Login type you select determines which fields are available on the Logins window.
3. Complete the fields using the information below.
• Name
Enter the Host Login name. If you need to create two or more Logins with the same name, you can append
an '@' character followed by any number of characters (up to 32 total) to the end of a Login name. The '@'
 Applications Manager 9.4.1

and characters after it will be stripped off before the name is passed to a Job. For example, if two hosts
(sun1 and dg1) both use the same Login name, add '@sun1' and '@dg1' to the Login names in order to
distinguish them from one another: am@sun1 and am@dg1.
• Type
Identifies the Login type you selected on the Select Login Type window. In this case HOST.
• Password
Enter the host password.
• Host IP
Enter the machine name or IP address of the host.
• Encrypted
Applications Manager automatically encrypts the password and checks the Encrypted field when you click
OK. You cannot change the Encrypted setting.
Testing the Connection
When you specify a Name, Password, and Host IP for a Host Login, you can test the connection using the Check
button.
The Check button uses regular FTP (not SFTP) to test the connection. If your server requires SFTP, this may result
in a failed test connection.
Using the Host Login
To use the Host Login in the FTP_JAVA Job, select it from the Remote Machine UserId prompt. To use the Host
Login in the FTP Job enter dblogin in the Fully Pathed Netrc Filename prompt and assign the Host Login to the
Job on its Login tab.

LOADER Job
Use the LOADER Job to run Oracle's SQL*Loader program for loading data into a database. The Job often follows
the FTP Job in an Applications Manager Process Flow.
The LOADER Job as well as the AWLOADP Program Type that used to be installed with new installs are now
included in the LOADER.exp import file.
Applications Manager 9.4.1
 Applications Manager 9.4.1

The image above shows the LOADER Job in the Submit window. The Job has a total of 12 prompts that let you
enter the standard parameters required to run the SQL*Loader program.
The prompt descriptions were taken from the Oracle7 Server Utility User's Guide published by Oracle Corporation.
For additional information about the SQL*Loader program, see your Oracle documentation.
Prompt Descriptions
The LOADER Job includes the prompts shown above. The prompts are described below.
• Control File Name
Enter a fully pathed control file name including the .ctl extension.
• Data File Name
Enter a fully pathed data file name. If the value for this prompt contains a regular expression wild card (i.e. *, %)
all matching files will be processed. These multiple input files will be concatenated first before running a single
SQL*Loader program. The individual input files will be stored in the Applications Manager output management
system.
• Abort on Bad Records
Select Yes or No from the list of values. When set to 'Yes,' the process aborts if the number of characters in the
SQL*Loader 'Max Size of Bad File' setting exceeds its defined limits.
• Max Size of Bad File
Sets the number of characters that defines a bad file. If the number of characters exceeds this number, the Data
File will be considered bad.
• Direct Load
Select Yes or No from the list of values. When set to 'Yes,' it enables the direct load option.
• Compress Data Files
Select Yes or No from the list of values. When set to 'Yes,' the data files are compressed prior to storing the
outputs.
• Use Extension Control
Select Yes or No from the list of values. When set to 'Yes,' only data files with completed transmission files
are processed. The completed transmission file must have the same path and file name, however it can have
different extensions. Prompts 08 and 09 define the different extensions.
• Data File Suffix
Enter the suffix of the file that will be loaded.
• Completed File Suffix
Enter the completed transmission file suffix.
• Log File Name
Create a file name that will be used for the log of the output. Do not include path information.
• Discard File Name
Create a file name that will be used to store the discarded records. Do not include path information.
• New Data File Name
Create a name for the new data file that is created. Do not include path information.

Running Custom Applications from Applications

Manager
To run a custom application within the Applications Manager environment, a Program Type must exist to support
the application. The function of the Program Type is to set up the environment necessary for the program to run
properly as well as pass desired data to the program.
To provide a link between the Applications Manager Program Type and the program you want to run, you write a
custom Program Type script. While this requires that you do some scripting, you write only one script that can be
used for all programs run by the Program Type. This is in keeping with the Applications Manager object-oriented
approach.
Six Main Tasks
 Applications Manager 9.4.1

The Program Type script must perform all the main work of running the task. Specifically, the interface script must
accomplish six main tasks:
• Program execution
• Parameter passing
• Error determination
• Output registration
• Debug/administration
• Termination
How Applications Manager Uses Program Type Scripts
When a Job is submitted, the Agent creates the pm<seq_no>.sh file where <seq_no> is a unique sequence
number determined by the $seq_no variable for UNIX or %seq_no% for Windows. The Agent then launches the
BODY script. After any applicable SYSOUT and PREFIX scripts are run, the BODY script executes the Program
Type script named by the Applications Manager Environment Variable $host_command. This variable holds the
name of the Program Type script. For example, if the SHELLS Program Type script is used, then $host_command
will equal SHELLS. This is the section of the BODY script where the actual task is run. The Program Type script
passes the Job prompts contained in the pr<seq_no>.sh file to the program. All remaining lines of the BODY
script deal with evaluating execution requirements, updating statuses, and running COMPLETION, TROUBLE, and
SUCCESS scripts. The sequence of events is illustrated below.

The table below describes the processes that occur in each of the stages shown above.

Stage Process Results

1 Automation Engine Checks status and runs BEFORE

conditions.

2 Agent Creates PR file (pr<seq_no>.sh)

and PM file (pm<seq_no>.sh).
Checks status.

3 PM Script Tests environment and launches

BODY script.

4 BODY Script Runs SYSOUT (System Output) and

PREFIX run-time scripts.

5 Program Type Script Runs program and passes PR file

(pr<seq_no>.sh).

6 Program Generates report output files and

return code.
Automation Engine
Automation engine checks DURING
and DELETED conditions.
 Applications Manager 9.4.1

Stage Process Results

7 Program Type Script Reads return code, checks errors,

registers output.

8 BODY Script Checks status. Runs TROUBLE,

SUCCESS, and COMPLETION run-
time scripts

9 Agent Reads final status.

10 Automation Engine Runs AFTER conditions and writes a

record to History.

Understanding Program Type Objects

A Program Type is an Applications Manager object that specifies how Applications Manager will interface with an
application. The Program Type is part of a Job definition.
In every Job, there is a field called Type that must be filled in for the Job to run correctly. The drop-down list in this
field displays a number of predefined Program Types that support most applications that you may need to interface
with Applications Manager. A Program Type defines:
• The format used to write prompts to the par (pr<seq_no>.sh) file.
• Login specifications.
• The name of the host command (Program Type script).
• A portion of the path for the program.
• The program's file extension.
In the image below, the AWSQLP Program Type is assigned to the EMPLOYEE_REPORT Job.
 Applications Manager 9.4.1

The image below shows the AWSQLP Program Type.

 Applications Manager 9.4.1

For information on creating Program Type objects, see Defining Program Types.

Understanding Program Type Scripts

Behind every Program Type object is a Program Type script. The Program Type script performs all the main work of
running the program specified in a Job definition. Specifically, the Program Type script accomplishes one or more
of the following six tasks:
• Program execution
• Parameter passing
• Error determination
• Output registration
• Debug/administration
• Termination
How a Program Type Script is Executed
When a Job is submitted, the Agent creates the pm<seq_no>.sh (UNIX) or pm%<seq_no>%.sh (Windows)
file and launches the BODY script. After any applicable SYSOUT and PREFIX scripts are run, the BODY script
executes the Program Type script named by the Applications Manager Environment Variable host_command.
 Applications Manager 9.4.1

This variable holds the name of the Program Type script. For example, if the SHELLS Program Type script is used,
then host_command will equal SHELLS. This is the section of the BODY script where the actual task is run. The
Program Type script passes the prompts contained in the pr file to the program. All remaining lines of the BODY
script deal with evaluating execution requirements, updating statuses, and running COMPLETION, TROUBLE, and
SUCCESS scripts.

Sample UNIX Program Type Script

Below is a listing of the EXEC Program Type script. The line numbers have been added for reference and do not
appear in the actual script.

1 :
2 #!/bin/sh
3 #copyright 2007 by Automic Software GmbH
4 # $Header:
/isa/devel/soport/so/dev/sostage/RCS/EXEC-EXECS,v
1.2 1998/02/24 19:06:46 billw Exp $
5 arg="$program `$SQLOPER_HOME/exec/ONELINE $par`"
6 eval $arg
7 err=$?
8 if [ -f $file ]; then
9 $AW_HOME/exec/FILESIZE $file $err
10 err=$?
11 fi
12 if [ -f $OUTPUT/$file ]; then
13 file=$OUTPUT/$file;export file
14 $AW_HOME/exec/FILESIZE $file $err
15 err=$?
16 fi
17 exit $err

The table below lists the key functions a Program Type script must perform, and the corresponding lines in the
EXEC program.

Function Line(s) Notes

Program execution 6 Accomplished with the eval

command. Note that 'arg' includes
the $program variable.

Parameter passing 5 Accomplished with ONELINE and

$par.
 Applications Manager 9.4.1

Function Line(s) Notes

Error determination 7, 10, 15, 17 The code err=$? traps the exit status
of the last command executed.

Output registration 9, 14 Accomplished by FILESIZE.

Debug/administration --- Not present in this script.

Termination 17 Accomplished with exit command.

'$err' traps exit code.

Sample Windows Program Type Script

Below is a listing of the EXEC Program Type script. The line numbers have been added for reference and do not
appear in the actual script.

1 @echo off
2 rem Copyright 2007 Automic Software GmbH
3 echo 'In EXECS'
4 echo 'calling'%program%
5 call %SQLOPER_HOME%\bin\oneline %SQLOPER_HOME%\run\%par%
6 call %SQLOPER_HOME%\c\ntspawn "%program% %args%"
7 if errorlevel 1 set err=%errorlevel%

The table below lists the key functions a Program Type script must perform, and the corresponding lines in the
EXEC program.

Function Line(s) Notes

Program execution 6 Accomplished with the ntspawn

command.

Parameter passing 5 Accomplished with ONELINE and

%par%.

Error determination 7 The code err=%errorlevel% traps

the exit status of the last command
executed.

Output registration --- Not present in this script.

Debug/administration --- Not present in this script.

Termination --- Not present in this script.

Program Execution
It is the Applications Manager Program Type script that actually runs the program selected in a Job definition. While
you can use any standard command to execute a program from within a Program Type script, the command used
by Applications Manager Program Type scripts is 'eval' in UNIX and 'call' in Windows. Eval evaluates parameters,
then executes the command.
For SQL*Plus scripts in UNIX, the pipe command is used to direct a string of commands to SQL*Plus.
UNIX Program Type Script Code
 Applications Manager 9.4.1

In a typical UNIX Program Type script, the code that executes the program would look as follows (code in bold):

1 :
2 #!/bin/sh
3 #Copyright 2007 Automic Software GmbH
4 # $Header:
/isa/devel/soport/so/dev/sostage/RCS/EXEC-EXECS,v 1.2 1998/02/24 19:06:46 billw Exp $
5 arg="$program `$AW_HOME/exec/ONELINE $par`"
6 eval $arg
7 err=$?
8 if [ -f $file ]; then
9 $AW_HOME/exec/FILESIZE $file $err
10 err=$?
11 fi
12 if [ -f $OUTPUT/$file ]; then
13 file=$OUTPUT/$file;export file
14 $AW_HOME/exec/FILESIZE $file $err
15 err=$?
16 fi
17 exit $err

On the first pass, eval evaluates $program and $par. It then executes the program.
UNIX Pipes
Pipes are used by programs that accept inputs from the standard input device. Normally, standard input would be
the user's terminal and/or keyboard. If you pipe output from the Program Type into the program, then the program
is taking its standard input from the program type.

$program <$par

A more complex example used within the Applications Manager SQL*Plus (SQLP) Program Type script is shown
below.
UNIX SQL*Plus Program Type Script Code
In a typical UNIX SQL*Plus Program Type script, the code that executes the program would look as follows (code
in bold):

#!/bin/sh

#Copyright 2007 Automic Software GmbH

# $Header: /isa/devel/soport/so/dev/sostage/RCS/EXEC-SQLP,v 1.1
1996/01/22 09:42:26 soport Exp $
#
echo PATH Is
echo $PATH
if [ "$DEBUG" = "YES" ]; then
env
set -x
echo "in $0"
 Applications Manager 9.4.1

fi
if [ -f $program.sql ]; then
err=0
else
echo "file $program.sql does not exist"
exit 1
fi
echo sqlp `date`
echo $ORACLE_PATH
echo sqlplus -s @$program A$seq_no.lis $argu
echo "define so_outfile=A$seq_no.lis" >> $par
echo start $program >> $par
logtest=login.$$
echo "$login
spool $logtest
prompt got it
spool off
start $par A$seq_no.lis $argu
"|sqlplus -s
err=$?
if [ -f $logtest ]; then
rm $logtest
else
echo Could not login to sqlplus
err=1
fi
echo sqlp `date`
if [ -f A$seq_no.lis ]; then
mv A$seq_no.lis $file
fi
$AW_HOME/exec/FILESIZE $file $err
err=$?
exit $err

The code is a series of SQL commands that are passed into SQL*Plus.
Windows Program Type Script Code
In a typical Windows Program Type script, the code that executes the program would look as follows (code in bold):

@echo off
rem Copyright 2007 Automic Software GmbH
echo 'In EXECS'
echo 'calling'%program%
call %SQLOPER_HOME%\bin\oneline %SQLOPER_HOME%\run\%par%
call %SQLOPER_HOME%\c\ntspawn "%program% %args%"
if errorlevel 1 set err=%errorlevel%

The "call" command executes the program using the values stored in the 'args' variable.
To be able to kill a process launched by a Windows task (Program Type script), the process must be launched by
the ntspawn executable as shown in the sample code above. Ntspawn launches the requested process and then
waits for the process to exit. If a kill task is issued while the process is running, ntspawn will kill the process and
 Applications Manager 9.4.1

return an error code. If the requested process is not launched with ntspawn, the kill task request will kill the cmd
shell that launched the process, but most likely will not kill the launched process.
The syntax for ntspawn is:
Usage: ntspawn command [args]
Example: ntspawn c:\mydir\myexe.exe arg1 arg2 arg3
Option -l: Creates lockfile for Agent.
Option -t <seconds>: Time out value. If task runs longer than <seconds> task will be killed.
Option -i: Ignore DOS error file for exit code checking.
Option -s: Silent. Do not print process header information.
Windows SQL*Plus Program Type Script Code
In a typical Windows SQL*Plus Program Type script, the code that executes the program would look as follows
(code in bold):

@echo off
rem Copyright 2007 Automic Software GmbH
echo 'In EXECS'
echo 'calling'%program%
call %SQLOPER_HOME%\bin\oneline %SQLOPER_HOME%\run\%par%
call %SQLOPER_HOME%\c\ntspawn "%program% %args%"
if errorlevel 1 set err=%errorlevel%

E:\AM\46NT_on_Dell\Master\exec>type sqlp.bat
if Not "%DEBUG%" == "YES" goto notdebug
set
echo on
echo in %0
:notdebug
if exist %program%.sql goto exists
echo "output file %program%.sql does not exist"
set err=1
goto end_of_it
:exists
echo in %0
echo plus31 -s @%program% A%seq_no%.lis %argu%
set err=0
echo define so_outfile=A%seq_no%.lis >> %par%
echo start %program% >> %par%
echo quit >> %par%
SET awsqlplus=c:\orant\bin\plus80.exe
echo %SQLOPER_HOME%\c\ntspawn "%awsqlplus% -s %db_login%/ passwd @%PAR% A
%seq_no%.lis "
call %SQLOPER_HOME%\c\ntspawn "%awsqlplus% -s %LOGIN% @%PAR% A%seq_no
%.lis "
if errorlevel 1 set err=1
if exist %file% del %file%
if exist A%seq_no%.lis move A%seq_no%.lis %file%
if not exist %file% echo no output from %module%
if exist %file% call PRINTEM
 Applications Manager 9.4.1

:end_of_it

The code is a series of SQL commands that are passed into SQL*Plus.

Parameter Passing
The format used to write prompts to the parameter (pr) file is defined in the Program Type window shown below.
However, the actual passing of the parameters is accomplished within the Program Type script.

Different applications demand parameters to be passed in different ways.

ONELINE
The Applications Manager script ONELINE, located in the exec directory, can be executed with the par
environment variable as an argument to convert each of the prompt entries in the parameter file to entries on one
single line separated by spaces (see the AWEXECS Program Type script). The code used to execute ONELINE is
shown below.
 Applications Manager 9.4.1

UNIX:

arg="$program `$AW_HOME/exec/ONELINE $par`"eval $arg

Windows:

call %SQLOPER_HOME%\bin\oneline %SQLOPER_HOME%\run\%par%

This executes identically to programs running on the command line. The output of the ONELINE script may then
be used as the arguments to be passed to the application to be run. The application may demand that specific
environment variables have values, and these values may need to be set by parsing the parameter file within the
Program Type script.
For example, assume the parameter file contains the following four values:

Jan
Feb
Mar
Apr

When arg is evaluated, the code would look like this:

UNIX:

$program Jan Feb Mar Apr

Windows:

%program% Jan Feb Mar Apr

par vs. so_par

The ONELINE program can be used with the par or so_par environment variables. par holds only the name of the
parameter file. so_par is the fully pathed file name of the parameter file.
For example, if the parameter file is pr3212.sh, then par would be pr3212.sh and so_par would be
$SQLOPER_HOME/run/pr3212.sh (UNIX) or %SQLOPER_HOME%\run\pr3212.sh (Windows).
PAR Passing
With SQR programs, you can pass in the parameter file using the so_par or par environment variable. For
example:
UNIX:

arg="sh $program $so_par

eval $arg
 Applications Manager 9.4.1

Windows:

call %program% %so_par

When this program is evaluated, it will look like this:

UNIX:

sh $program $AW_HOME/run/pr<seq_no>.sh

Windows:

%program% %AW_HOME\run\pr<seq_no>.sh

where pr<seq_no> is a unique number produced by the Applications Manager Agent.

Using Environment Variables
If a program accepts input and output file names from environment variables, you can set the environment
variables in the Program Type script. In the example shown below, the program writes its output to OUTFILE, and
gets the parameters from INFILE.
UNIX:

OUTFILE=$file; export OUTFILE

INFILE=$par; export INFILE
$program

Windows:

set OUTFILE=%file%
Set INFILE=%par%
Call %program%

Output Registration
To register output in Applications Manager, you run FILESIZE as part of the Program Type script with the file name
and exit error value as arguments.
The code is:
UNIX:

$AW_HOME/exec/FILESIZE $file $err

 Applications Manager 9.4.1

Windows:

%AW_HOME%\exec\FILESIZE %file% %err%

The FILESIZE script is located in the exec directory under AW_HOME.

FILESIZE Function
FILESIZE registers the program output file.
• If the variable file in the Program Type script contains only the name of the file, FILESIZE moves the program
output file from the current directory to the out directory under AW_HOME. Example:
UNIX:

file=$jobid.log
$AW_HOME/exec/FILESIZE $file $err

Windows:

set file=%jobid%.log
If exist %file% call filesize %file% %err%

• If the variable file in the Program Type script contains a pathed file name, FILESIZE leaves the file in its original
directory. Example:
UNIX:

file=/accounting/reports/$jobid.log
$AW_HOME/exec/FILESIZE $file $err

Windows:

set file=\accouting\reports\%jobid%.log
if exist %file% call filesize %file% %err%

Either way, FILESIZE records the location of the program output file. FILESIZE does not register the standard out/
log file. Instead, the standard out/log file is placed in the default output directory (out) by the BODY script.
When you view the output from a task in the Backlog or History, you see the locations of the output files in the
Output Files tab. The image below shows an example of UNIX output files.
 Applications Manager 9.4.1

Registering Multiple Output Files

To avoid overwriting the same output file with multiple executions of the same program, use the Applications
Manager Environment Variable file. By default, the value of file is b.$jobid (UNIX) or o%jobid%.lis (Windows).
The default name for your files may be redefined by editing the awenv.ini file. For more information, see the
Administration Guide.
jobid has only one value per execution of a task, so to register more than one output file, do not use the file
variable. Instead, use jobid with an extension to make each file unique (example: $jobid.log1, $jobid.log2, etc.).
The FILESIZE script should then be used on each of these individual files.
Changing the Output Directory
The Applications Manager Environment Variable OUTPUT holds the value $AW_HOME/out (UNIX) or
%AW_HOME\out% (Windows) by default. This is set as part of the definition of the Automation Engine Agent. If the
OUTPUT variable is reset in the Program Type script (or from the User or Jobs windows) before FILESIZE is run,
Applications Manager will move the output file to the specified location instead of the default location. This will work
only if the variable file contains just the file name. If file contains a pathed file name, OUTPUT is ignored.
The sample script below shows the use of OUTPUT:
UNIX:

file=$seq_no.log
OUTPUT=/accounting/reports
$AW_HOME/exec/FILESIZE $file $err

Windows:

set OUTFILE=%file%
set INFILE=%par%
call %program%
 Applications Manager 9.4.1

Error Trapping
To update statuses of tasks correctly, Applications Manager must trap the exit values of the processes, and the
Program Type script must exit with this value. This is accomplished by including the appropriate error trapping code
in the Program Type script.
In addition to capturing the error code for a single process, you may want to capture cumulative errors for multiple
processes, ensuring the script exits with an error code even if one process fails but the next process succeeds.
Some processes such as FTP and Oracle may have errors, but still exit with a zero exit value. With these types
of processes, you may have to search for specific text strings in the log files to determine whether the process
completed successfully.
The code you use to trap errors is different for UNIX and Windows. Each is described separately in the following
subtopics.

Error Trapping in UNIX

To trap errors in UNIX, you add the following code to the Applications Manager Program Type interface script:

err=$?
exit $err

$? represents the status of the last command not executed in the background. If the command executes
successfully, $? will equal zero. If it does not execute successfully, $? will equal a value other than zero. A task that
returns an exit status of zero is marked as FINISHED in the Backlog and History. A task that returns a value other
than zero is marked ABORTED.
Always put this code after the eval statement in a script, not after any echo statements. If you put the code after an
echo statement, it will capture the error value for the echo statement.
Capturing Cumulative Errors
You may want the script to exit with an error code even if one process fails but the next process succeeds. This is
accomplished with the following code:

err=`expr $? + $err`

The expression adds the error code from the current process to the error code of the previous process. This is
particularly useful after running FILESIZE in a Program Type script.
Searching for Text Strings
Some processes such as FTP and Oracle may have errors, but still exit with a zero exit value. With these types
of processes, you may have to search for specific text strings in the log files to determine whether the process
completed successfully. One example of this is illustrated within the FTP Program Type script by the following lines:

#grep for "transfer complete" from ftp sysout

#and count the lines returned
check=`cat ftp.$seq_no|grep -i 'transfer complete'|wc -l`

#if no 'transfer complete' lines were found

#the ftp was not successfull
if [ $check -eq 0 ]; then
#set the return status to non zero and display message
echo "Error detected"
err=2
 Applications Manager 9.4.1

fi

Error Trapping in Windows

To trap errors in Windows, you add one of the following sets of code to the Applications Manager Program Type
interface script:

if errorlevel 1 set err=1 [sets err to 1]

exit /B %err%
if errorlevel 1 set err=0 [sets err to 0]
exit /B %err%
if errorlevel 1 set err=%errorlevel% [sets err to real value]
exit /B %err%

%err% represents the status of the last command. A task that returns an exit status of zero is marked as
FINISHED in the Backlog and History. A task that returns a value other than zero is marked ABORTED.
Always put this code after the call statement in a script, not after any echo statements. If you put the code after an
echo statement, it will capture the error value for the echo statement.
Capturing Cumulative Errors
You may want the script to exit with an error code even if one process fails but the next process succeeds. This is
accomplished with the following code:

set /a err=%err% + %errorlevel%

The expression adds the error code from the current process to the error code of the previous process. This is
particularly useful after running FILESIZE in a Program Type script.
Searching for Text Strings
Some processes such as FTP and Oracle may have errors, but still exit with a zero exit value. With these types
of processes, you may have to search for specific text strings in the log files to determine whether the process
completed successfully. One example of this is illustrated within the FTP Program Type script by the following lines:

print "checking file ftp results\n";

#$check=`type ftp2.$seqnoenv|grep -i "transfer complete" `; #end

open(FTPTMP,"ftp2.$seqnoenv");
while (<FTPTMP>) {
chop;
if (/ransfer complete/){
$check=$_;
}
}

close(FTPTMP);

print "check $check\n"; #end

if ( "$check" eq "" ) {
printf( "Error detected.\n");
$err=2;
 Applications Manager 9.4.1

}
print "done.\n";

DEBUG/Administration and Termination

By adding code for debugging, Applications Manager can assist if errors occur during task execution. When a script
terminates, it should trap errors, delete old output files, and delete unneeded files created by the program.
DEBUG/Administration
Code should be included in the Program Type script that will allow for debugging should errors occur within the
program. Useful expressions include those that list the values of environment variables currently set, each of the
commands actually executed, current times to see where a Program Type script is, and structures to check the
existence of a file containing a program to be run. Applications Manager Program Type scripts generally include
some or all of the commands listed in the following table.

Command/Structure Purpose/Function

UNIX: set -x Writes commands and arguments as executed to

SYSOUT.
Windows: @echo on

UNIX: set or env Writes the values of all environment variables to

SYSOUT.
Windows: set

UNIX: echo $0 `date` Writes the current command and current time.
Windows: date /t

UNIX: if [ -f $program.sql ]; Checks for the existence of the file program.sql and
sets the variable err equal to 0 if found.
then err=0
Windows: if exists %program%.sql
set err=0

You can control whether the above commands are active by including code that searches for the Applications
Manager DEBUG file as shown in the following script:
UNIX:

if [ "$DEBUG" = "YES" ]; then

env
set -x
echo "in $0"
fi

Windows:

if "%DEBUG%" = "YES" set

if "%DEBUG%" == "YES" @echo on

In the UNIX code, $0 returns the name of the program or script.

Activating DEBUG
You activate DEBUG by creating an empty file called DEBUG in the run directory under AW_HOME by issuing the
touch DEBUG command. When DEBUG is active, it applies to all Jobs that are run.
 Applications Manager 9.4.1

Viewing the Log

To view the output log, go to the out directory and find the most recent 'o' file. It should be larger than any of the
other output files. The number associated with the 'o' file is the run ID number. This will help you to find the right
output for the right task.
Canceling Debug
After you have obtained the log file you need, remove the DEBUG file from the run directory.
Termination
When a script terminates, it should:
• Trap errors.
• Delete old output files.
• Delete unneeded files created by the program.

Installed Program Types and Program Type Scripts

The following tables describe the Program Types that are shipped with Applications Manager and their supporting
Program Type scripts. There are additional Program Type scripts that ship with Applications Manager. To use these
scripts, you can define a new Program Type in Applications Manager. All Program Type scripts are located in the
exec subdirectory.
UNIX Program Types
The list below describes the key UNIX Program Types that ship with Applications Manager and their supporting
Program Type scripts. The Program Type scripts are located in the exec subdirectory.

Program Type Program Type Script Description

BOURNE SHELLS Runs a Bourne or Korn shell script,

but does not register output.

AWEXECS EXECS Runs a Bourne or Korn shell script,

and registers output.

FRMP FRMP Runs Oracle form 30.

AWLOADP SHELLS Runs SQL*Loader tasks used to

load a flat text file into a database.
The LOADER Job as well as the
AWLOADP Program Type that used
to be installed with new installs are
now included in the LOADER.exp
import file.

RPTP RPTP Runs Oracle reports tasks.

AWSHELLS SHELLS Runs a Bourne or Korn shell script,

but does not register output.

SHUTDOWN SUSOSHUT Shuts down Applications Manager,

runs the specified program, then
restarts Applications Manager.

SOSHELLS SHELLS Runs embedded SQL.

AWSQLP SQLP Runs SQL*Plus scripts.

AWSQRP SQRP Runs SQL*Reports programs

AWSRWP SRWP Runs SQL*Writer programs

 Applications Manager 9.4.1

Program Type Program Type Script Description

AWSURUNP SURUNP Runs scripts under a different User's

Login.

AWJAVA AWJAVA Runs Java scripts.

Windows Program Types

The list below describes the key Windows Program Types that ship with Applications Manager and their supporting
Program Type scripts. The Program Type scripts are located in the exec subdirectory.

Program Type Program Type Script Description

APPWORX_SHELLS bats.bat Runs shell scripts.

AWJAVA AWJAVA.BAT Runs Java scripts.

AWLOADP loadp.bat Runs SQL*Loader tasks used to

load a flat text file into a database.

AWSHELLS EXECS.BAT Runs executable programs.

AWSQLP sqlp.bat Runs SQL*Plus scripts.

AWSQRP sqrp.bat Runs SQL*Reports programs.

AWSRWP srwp.bat Runs SQL*Writer programs

AWSURUNP SURUNP Runs scripts under a different User's

Login on a UNIX Remote Agent.

SHUTDOWN SUSOSHUT Shuts down Applications Manager,

runs the specified program, then
restarts Applications Manager.

Run-Time Extensions and Environment Variables

Run-time extensions and environment variables are features Applications Manager administrators can use to add
functionality to Applications Manager.
You can write shell scripts that Applications Manager will run before a task executes, when a task completes
successfully, when a task does not complete successfully, or when a task completes without regard to its
completion status. In Applications Manager, the shell scripts are called run-time extensions.
The shell scripts can apply to every task, or tasks identified by Job, User, Application, or command. Any valid shell
(Bourne shell for UNIX or batch scripts for Windows) script can be used as a run-time extension as long as the
script is stored in the exec directory of the Agent where the task runs.
Warning: Run-time extension scripts are invoked as part of the Applications Manager computation
process. Errors in the scripts can cause the process status to change to DIED. This means that the process
went away without signaling its completion status. This affects the normal completion process. Scripts must
be Bourne shell in UNIX and batch scripts in Windows.
Typical Uses
Typical uses for run-time extensions include:
• Restarting tasks
• Renaming output files
• Moving output files
Applications Manager System Environment Variables
 Applications Manager 9.4.1

There are a number of Applications Manager environment variables that can be used in shell scripts. The variables
provide information about the Applications Manager environment, Jobs, and Process Flows. For more information,
see Using Applications Manager System Environment Variables.
EXIT Commands Not Allowed
You should not include EXIT commands in your run-time extension scripts. If any run-time extension includes an
exit or syntax error, Applications Manager will not be able to complete processing the task and the task status will
be displayed as DIED.
Scanning Output, Sending Notifications, and Setting Environment Variables with Applications Manager Objects
You can scan text in output files with Applications Manager Output Scan objects to indicate whether a task has
failed or succeeded. Output Scans are assigned to Jobs and Program Types. Each Output Scan includes one or
more rules. For more information, see Defining Output Scans.
You can send output from Output Scans to one or more email addresses or Applications Manager Output Devices
by defining Applications Manager Notifications and assigning them to Applications, Program Types, and Jobs. For
more information, see Defining Notifications.
You can define and store values for one or more environment variables as a single Applications Manager object.
Environment variables are assigned to Agents, Applications, Program Types, and Jobs. Their values are written to
the .pm file after other environment variables are set. For more information, see Defining Environment Variables.

How Run-Time Extensions Work

You can write shell scripts that Applications Manager will run before a task runs, when a task completes, completes
successfully, or does not complete successfully.
The logic that checks for and runs the run-time extensions is included in the BODY program located in the exec
directory of the Agent where the task runs.
Typical uses for run-time extensions are:
• Restarting tasks
• Renaming output files
• Moving output files
Types of Run-Time Extensions
There are four types of run-time extensions. Of these, only PREFIX scripts execute before a Job runs.

Extension Type Description

PREFIX Runs before a task runs.

TROUBLE Runs when a task returns a non-zero error code.

SUCCESS Runs when a task returns an error code of zero.

COMPLETION Runs when a task completes regardless of the

completion status.

Running Scripts with BEFORE Conditions

Trouble run-time scripts do not run when tasks are aborted by a BEFORE condition. This is because BEFORE
conditions are evaluated before the BODY script runs. BODY executes any TROUBLE, SUCCESS, or
COMPLETION scripts. To run a script with a condition, use the RUN HOST COMMAND action. For more
information on conditions, see chapter Working with Conditions.
General vs. Specific Run-Time Extensions
A run-time extension can apply to every task, or to tasks classified by Application, User, Program Type, Job, or
command. The run-time extension script's name determines when a script will execute. For example, the PREFIX
run-time extension can take the following file names:
 Applications Manager 9.4.1

File Name Description

PREFIX Runs before every task.

Example: PREFIX would run before every Job.

PREFIX.<Application> Runs before any Job associated with the Application.

Example: PREFIX.FINANCE would run before any Job
associated with the FINANCE Application runs.

PREFIX.<User> Runs before any Job requested by the User.

Example: PREFIX.SQLOPER would run before any
task submitted by User SQLOPER runs.

PREFIX.<Program Type> Runs before any Job that has been assigned the
specified Program Type.
You must use the name of the Program Type, not the
name of the interface script.
Example: PREFIX.AWSQLP would run before any Job
that has been assigned the AWSQLP Program Type.

PREFIX.<Job> Runs before the Job runs. Uses the alias name in the
Backlog.
Example: PREFIX.DELPRINT would run before the
DELPRINT Job is run.

PREFIX.<command> Runs before any Job that runs the specified program
command.
Example: PREFIX.test would run before any Job that
runs the TEST program.

The generic <Application>, <User>, <Program Type>, <Job>, and <command> file suffixes apply to all four types of
run-time extensions: PREFIX, COMPLETION, TROUBLE, and SUCCESS.
Execution Order
When using multiple run-time extensions, the order in which they run might be important for your implementation. If
multiple run-time extensions exist that could run for a particular task, the order in which they run is indicated by the
order in the table above, i.e. PREFIX runs first, PREFIX.<Application> runs next, and so on.
For example, Job ACCOUNTS in Application group FINANCIALS executes program REPORT. The Job is
requested by User SMITH. The following run-time extension scripts exist: TROUBLE, TROUBLE.ACCOUNTS,
TROUBLE.FINANCIALS and TROUBLE.SMITH. When Job ACCOUNTS finishes (with an error exit status), the
scripts run in the following order: TROUBLE, TROUBLE.FINANCIALS, TROUBLE.SMITH, TROUBLE.ACCOUNTS.
On Windows systems, you must add a .bat extension to the run-time extension scripts or they will not run.

UNIX Run-Time Extension Examples

Several run-time extension examples are presented below. In the code samples, the cat command used to display
the code is shown in bold type. Keep in mind that these are just examples. Several of the functions these scripts
provide can be accomplished using core features in the Applications Manager client such as conditions, Output
Scans, and Notifications.
Flagging Nonfatal Errors by Changing Task Status
You can use the SUCCESS run-time extension to check for specific error codes in the output files for the task. For
example, it is possible for SQL*Plus to exit with a zero error status and a status of FINISHED despite having Oracle
 Applications Manager 9.4.1

errors. This script looks for these errors only in successful SQLP Program Types and returns a WARNING status
when Oracle errors are detected.

$ cat SUCCESS.SQLP
ck_err=`cat $stdout|grep 'ORA-'|grep -v '<Oracle errors to be excluded>'|wc -l`
echo 'Oracle Errors Detected: '$ck_err
if [ $ck_err -ne 0 ]; then
show_status='WARNING'
status='FINISHED'
fi

This run-time script executes after the SUCCESS of any Job that uses the SQLP Program Type. It checks the
standard output file, looks for ORA- errors, and counts the number. The output file echoes the number of 'Oracle
Errors Detected.' Finally, it will change the status from FINISHED to WARNING, thus allowing other tasks to
continue running.
Overriding Status
If errors exist, you can use a run-time extension script to change the status value in the Applications
Manager$status environment variable.

$ cat TROUBLE.FTP_TEST
#if ftp script fails and the user is SMITH it is only a warning
if [ $user = SMITH ]; then
show_status='WARNING'
status='FINISHED'
fi

Changing Displayed Status

Using a run-time script, you can change the status displayed for a task in the Backlog and History without changing
the actual status of the task. For example, suppose you are running a program called DATA_LOAD, and if the
program aborts, you want to display the status as BAD DATA instead of just ABORTED.

$ cat COMPLETION.DATA_LOAD
if [ $status = ABORTD -a $results -eq 3 ]; then
show_status='BAD DATA'
fi

Modifying the Output Path

There may be situations when you want to change the directory where output files are written when errors are
present in a task's log file. In the example below, output is written to the bin directory rather than the out directory
when errors are present for a user.

$ cat PREFIX.TEST_JOB
# This script should route output from standard output to <user>
OUTPUT1=/isa/users/
if [ $status = FINISHED ]; then
OUTPUT=$OUTPUT1
Echo 'This file was sent to output on ssmith'
 Applications Manager 9.4.1

fi

Mail to Completion Script

There may be times when you want to send an output email with the Job status message. It may be more
convenient to apply this 'generically' each time a particular Job runs. Conversely, if this is a recurring Job in
a Process Flow, you might consider using a condition statement for the specific Job instance. Below is the
encompassing script:

$ cat COMPLETION.TEST_JOB
# This script sends an email message and task status for a specific
# job.
echo "Your output status for $module $jobid is $status"\
|mailx -s"Job $module Status $status" $user

Using Applications Manager System Environment Variables

The variables described in this topic are available in the UNIX and Windows environments and may be defined
through the Applications Manager GUI or included in any run-time shell script. UNIX environment variables are
identified as $<variable name> and Windows environment variables are identified as %<variable name>%.
You can also create environment variables (assigned globally in sosite, with Environment Variable objects, or in
PREFIX run-time extensions) that are active in your run-time environment. A list of Applications Manager-reserved
words, those that should not be used or assigned within your Applications Manager environments, is listed in topic
Applications Manager Reserved Words.

Variable Description

app_path The Library path of the Job.

application The application of the Job.

chain_id A unique ID number assigned to a Process Flow each

time the Process Flow is initiated. All members of a
Process Flow use the same Process Flow_id, including
all sub Process Flows.

chain_seq A unique number assigned to a Process Flow at the

time the Process Flow is created.

CLEAN=YES/NO A variable that denotes whether or not the files in

process should be deleted when the process exits.
Useful when debugging new shells. If not assigned,
Applications Manager default behavior = 'YES.'

command The name of the program to run.

command_dir The subdirectory for the command type (if any).

copies The number of output copies to be printed.

db_login The Job's primary Database Login name taken from the
Database Login definition.

db_login2 The Job's secondary Database Login name taken from

the Database Login definition.

db_password The Job's primary Database Login password taken from

the Database Login definition.
 Applications Manager 9.4.1

Variable Description

db_password2 The Job's secondary Database Login password taken

from the Database Login definition.

db_type The type of database being accessed.

DEBUG=yes/no Used to debug new shells.

If not assigned, Applications Manager defaults to 'no'.

file A unique file name usually used as the output file name.

full_login2 The secondary Database Login and password under

which the program runs. For Oracle: login=#db_login/
$db_password$net_connect.

function The requested output function: LOG, PRINT, or STORE.

host_command The name of the Program Type interface shell script file.

Job_number A unique number assigned to a Job when the Job was

created.

jobid A run ID number assigned to a request. The decimal

part differentiates restarts of the same task. For
example: 25119, 25119.01, 25119.02, etc.

log_run=Y/N A flag (Y or N) that denotes whether the system output

from the task should be stored.

login The primary Database Login and password under

which the program runs. For Oracle: login=#db_login/
$db_password$net_connect.

login_sid The primary Login's ORACLE_SID value (or PDB

service name for Oracle 12c and above) for the Job, if
any.

login_sid2 The secondary Login's ORACLE_SID value (or PDB

service name for Oracle 12c and above) for the Job, if
any.

module The Job name, or the view name if the Job is part of a
Process Flow.

net_connect The database network connect string from the primary

Database Login definition.

net_connect2 The database network connect string from the

secondary Database Login definition.

orig_log_run Created by BODY (in Windows: BODY.bat). Preserves

the original values of the log_run.

OUTPUT The storage path of the output file if registered through

the FILESIZE shell.

output_required=Y/N Denotes whether output is required for a Job. If set to

'Y', and the Job does not produce output, the shell exits
with a non-zero status code. If not assigned, the default
is 'N'.
 Applications Manager 9.4.1

Variable Description

par The file name of the parameter file (if any), commonly
pr<seq_no>.sh. See also the 'so_par' entry in this
table.

printer Requested printer name.

printer_type Output Group assigned to the Job.

program The full path of the program. Contains: $app_path/

$command_dir/$command.

queue Queue where the task is running.

rpf_options Value of the Program options field on the Job's Output

tab.

seq_no A unique number assigned to a task each time it runs.

show_status Changes the status displayed for a task in the Backlog

and History without changing the actual status of the
task.

SO_OPERATOR The name of the Agent processing the request.

SO_OPERATOR and OPERATOR are identical.

so_par The fully pathed file name for the par file, usually
$AW_HOME/run/pr<seq_no>.sh. See also the 'par'
entry in this table.

source The Job's Program Type.

AW_HOME The path to the Applications Manager installation

directory. This replaces SQLOPER_HOME.

status The status of the task after it has run. Useful in run-time
extension scripts.

stdout The fully qualified filename of the system output of a

Job running.

user The requestor's name.

Applications Manager Reserved Words

The following is a list of Applications Manager reserved words. These words have exclusive meanings within
the Applications Manager environment. Do not create scripts that use these words unless they are used for their
intended environment variable purpose.
• app_path
• application
• APPLPATH
• APPWORX_SERVER
• AVERAGE_ACTIVITY
• aw_assoc
• AW_NOGRPS
• AW_OLDDP
• aw_qmgr_options
• AW_SINGLETHREAD
• batch_home
 Applications Manager 9.4.1

• BODY_PID
• chain_id
• chain_seq
• CLEAN
• COLLECTOR_PURGE_MINUTES
• COLLECTOR_SLEEP_TIME
• command
• command_dir
• CONC_DEBUG
• CONC_SHOW_LOG
• CONFLICTS
• copies
• db_login
• db_password
• db_type
• DEBUG
• DURING_WAIT
• file
• function
• host_command
• INITWAIT
• job_number
• jobid
• log_run
• login
• login_sid
• MASTER_STARTUP_SQL
• MAX_ACTIVITY_COUNT
• MAXFILES
• maxrows
• module
• MODULE_SETUP
• MODULE_SPAWN_PARMS
• MORAINIT
• MORANOINDEXINFO
• MORATOLOWER
• MSQLORDER
• MSYBNOINDEXINFO
• MYDBG
• net_connect
• NOTRANS
• NPCMD
• omgr_maxrows
• OPERATOR
• orig_log_run
• OUTPUT
• output_required
• par
• PARDIR
• PICTUREPATH
• printer
• printer_type
• program
• qblog_maxrows
• qhist_maxrows
• queue
 Applications Manager 9.4.1

• REMOTE_AWRUN
• REQUEST_SHELL
• REQUEST_TYPES
• RESPAWN_SUFFIX
• rpf_options
• seq_no
• SNMASTER
• SO_COLL_PATH
• SO_CONCFILE
• SO_DATA_PATH
• SO_DISCONNECT
• SO_DIST_PATH
• SO_HOST
• SO_DIST_PATH
• SO_HOST
• SO_IDX_PATH
• SO_MAINT_HOUR
• SO_NO_RETRY
• SO_NOCONNECT
• SO_OPERATOR
• so_par
• so_password
• SO_PRINTMGR
• so_process_time
• SO_RUN_NOPASSWORD
• SO_WAIT
• sologin
• SORUN_WAIT
• SOSTOP
• source
• SPAWN_DIR
• SQLOP_CVIEWER
• SQLOP_DAYS
• SQLOP_HISTORY
• SQLOP_HOST
• SQLOP_MENU
• SQLOP_MODPOP
• SQLOP_MSHELP
• SQLOP_ONCE
• SQLOP_SUBVAR
• SQLOP_SYSOUT
• SQLOP_USER
• AW_HOME
• status
• stdout
• TEMP
• time_out_factor
• TMPDIR
• user
• WatchWorx_max_idle
• WINDOWBACKEND
• WINTYPE
 Applications Manager 9.4.1

SURUN - Running UNIX Tasks Under Other Host Logins

Applications Manager contains a program called SURUN. This program allows Applications Manager to run tasks
(target programs) under different UNIX logins. To control the use of SURUN, you use an SURUN Program Type to
call SURUN and create an authoriz.lis file. This file specifies the users and programs that SURUN can use.

Overview
The diagram above demonstrates the design principle of SURUN. To use SURUN, create a Job specifying an
SURUN Program Type and the target program from the Program Name list. Set the Library equal to the location of
the target program you want to run.
During run-time, the SURUNP Program Type script determines which UNIX user owns the target program.
The Applications Manager UNIX user must have access to the target program. The SURUNP Program Type calls
the SURUN C program and passes the path, program name, and user information to the C program.
The C program switches to the owning user and runs the target program. SURUN checks the authoriz.lis file to
authorize the switch prior to executing the program.
If you are using SURUN to run a program that accepts arguments, you can define prompts for the Job, one prompt
for each argument. The prompt values will be passed to the program in the order they are listed in the Job.

Three SURUN Program Types

The SURUNP Job uses either the AWSURUNP, AWSURUNP_REQ, or AWSUSQLP Program Types. Program
Types perform the 'handshaking' with the SURUN C program. Each SURUN Program Type produces a different
action.
The first step to using the SURUN utility is to create a Job. The Job connects to the SURUN C program using one
of the SURUN Program Types, then passes the target program name to the SURUN C program.
 Applications Manager 9.4.1

Procedure
To create an SURUN Job:
1. Create a Job similar to the one shown above.
2. Create a Library and path that points to the location of the target program directory.
3. Select the AWSURUNP, AWSURUNP_REQ, or AWSUSQLP Program Type.
4. Select the program name.
Without permissions to view a User's directory or programs, the select list may be blank. Type in the target
program name (or assign read permissions to the UNIX account).
5. If the program requires parameters, create a prompt for each parameter.
6. Save the Job by clicking OK.
Choosing the Right Program Type
The AWSURUNP, AWSURUNP_REQ, and AWSUSQLP Program Types perform the 'handshaking' with the
SURUN program. Each Program Type provides different instructions for the SURUN program. All three interface
scripts ship with Applications Manager, however you must create the Program Types for AWSURUNP_REQ and
AWSUSQLP. A Program Type for AWSURUNP_REQ is shown below.
 Applications Manager 9.4.1

The scripts are stored in the $AW_HOME/exec directory. The Program Types are described in the following table.

Program Type Actions

AWSURUNP Locates the target program file, finds its owner, checks
the authoriz.lis file, changes to the UNIX user account
of the program owner, and runs the task from there.

AWSURUNP_REQ Behaves identically to AWSURUNP, except that it

switches to the UNIX account of the requestor (not the
program owner) and runs the target program in that
UNIX user account. If the requestor does not have a
matching UNIX account, the task is run as the default
Applications Manager UNIX user.
 Applications Manager 9.4.1

Program Type Actions

AWSUSQLP Locates the target program file, finds its owner, checks
the authoriz.lis file, connects to the SQL*Plus account,
logs in as the Applications Manager requestor, and runs
the program.
Name your SQL*Plus program without the .sql
extension. AWSUSQLP expects report output so you
need to define an Output Interface and device. Also
define the Database ID for the user connecting to
SQL*Plus. The requestor should be a valid UNIX user.

Creating an authoriz.lis File

The authoriz.lis file determines which users, tasks, and environments you can access using SURUN. Your UNIX
network administrator must assign root ownership for the SURUN program and optionally for the authoriz.lis file.
This is required since only the root user can switch to other users. To enable SURUN:
1. Create an authoriz.lis file.
2. Change ownerships to root for SURUN and the authoriz.lis file.
3. Change the access rights on authoriz.lis to 755 to restrict changing of this file to root only.
4. Set the Set User ID bit on SURUN.
Create an authoriz.lis file
Create a file in the exec subdirectory named authoriz.lis.
The authoriz.lis file has three columns: UNIX user id (USERID), fully pathed target program name (PROGRAM),
and SU preference (SU_TYPE). Each entry or line in the file provides 'permission' for one or more users to run one
or more programs. A sample authoriz.lis file is shown below:

USERID PROGRAM SU_TYPE

oracle /user/oracle/bin/dbshut
isa /user/am/exec/FILESIZE
* /user/am/exec/SUSQLP1
smith * 1
* /user/ryan/programs/myprog1
jones /user/jones/programs/myprog2 1
jones /user/jones/programs/myprog3

Paths used in the PROGRAM column must be fully and explicitly specified. You cannot use variables in the paths.
The columns should be TAB delineated.
An '*' in the USERID column authorizes any user to run the specified program. An '*' in the PROGRAM column
allows a user to run any program. As a security measure, you may NOT use an '*' in both the USERID and
PROGRAM columns for the same entry. Further, you may NOT use '*' in the PROGRAM column for any entry with
a USERID of 'root'.
SU_TYPE Explanation
The SU_TYPE column controls how SURUN switches to the specified user. If the column is blank, SURUN
switches to the user and leaves the Applications Manager environment intact (su). If the column has a '1', SURUN
switches to the specified user and makes that user's environment active. The Applications Manager environment
variables will NOT be available. The matrix below diagrams the possible options of an SURUN program.

SURUN Program Types If SU_TYPE = blank (su) If SU_TYPE = 1 (su-)

SURUNP Owner's Account Owner's Account

Applications Manager's Environment Owner's Environment
 Applications Manager 9.4.1

SURUN Program Types If SU_TYPE = blank (su) If SU_TYPE = 1 (su-)

SURUNP_REQ Requestor's Account Requestor's Account

Applications Manager's Environment Requestor's Environment

SUSQLP Requestor's SQL*P Account NOT ALLOWABLE

Applications Manager's Environment

Assign Ownership
After creating the authoriz.lis file, have your UNIX system administrator login as the Applications Manager
user. Issue the su command (retain the Applications Manager environment) and enter the root password when
prompted. Perform the following commands within the Applications Manager$AW_HOME/c directory:

mv c/surun c/SURUN
chmod 4711 c/SURUN
chown root c/SURUN
chown root exec/authoriz.lis
chmod 755 exec/authoriz.lis

This protects the SURUN program, allows only 'root' to modify the authoriz.lis file, and controls which commands
may execute.

Capturing Output
If the programs run by SURUN have output you want managed by Applications Manager, use the FILESIZE
command.

$SQLOPER_HOME/exec/FILESIZE $file $err

exit $err

You can add the command directly to the program, or make it part of the SURUN Program Type script. If you will be
running more than one program, and they all handle output in the same way, it is best to put the FILESIZE code in
the Program Type script. By putting the code in the Program Type script, you only have to maintain it in one place.
If the Applications Manager Login does not have read access to the output files generated, include a chmod
statement to give it access. If Applications Manager does not have read access to the directory, the file may need
to be moved to a common area (/tmp) so it can be read.
When Applications Manager captures output, it writes a temporary file to the $SQLOPER_HOME/run/
<Agent_name> directory. The SURUN user must be given write access to the directory.

SURUN Error Messages and SURUN Debugging

The following error messages may occur when you run the SURUN program.

Message Action to Take

Usage: SURUN <userid> <program> <arguments> Correct syntax and retry task.

<userid> is not a valid userid. The userid entered is not found in the /etc/passwd file.

Error executing program <program> The program either could not be executed or it executed
and terminated with a non-zero status. The value
Error Number = <value>
received as the exit status is displayed on the second
line.
 Applications Manager 9.4.1

Message Action to Take

Unable to change to uid of <userid>. SURUN could not change to the userid requested.
Change the owner to root and the access permissions
to 4711 on file SURUN.

User <userid> is not authorized to execute <program> The requested userid/program combination was not
found in the authoriz.lis file.

Cannot open authorization file. The authoriz.lis file is not located in the Applications
Manager exec directory or it was not accessible to
SURUN due to protection/ownership problems.

Debugging SURUN
To debug SURUN, add the following line to your SURUNP script:

AW_SURUNDEBUG=YES; export AW_SURUNDEBUG

When you re-run the SURUN task, debug information will be shown in the standard output file.
To turn SURUN debug off, remove or comment out the new line.

Applications Manager Command Line Utilities

Applications Manager includes three command line utilities that you can use to access Applications Manager
functionality from the system command line or a DOS prompt on the Automation Engine machine or an Agent
machine. They include:
• The awrun command
• The awexe commands
• The Applications Manager Command Line Interface
The awrun Command
Using the awrun command, you can run a task by inserting a row directly into the Applications Manager
JOB_QUEUE. When you issue the command, you specify the Job, options, and any necessary arguments. While it
is possible to insert records directly into the JOB_QUEUE table using database commands, we do not recommend
this approach. You should use awrun instead.
The arguments are the values used for prompts defined for the Job. awrun also can be used to call Applications
Manager from another Windows application. For security reasons, the use of awrun is User Group controlled.
The current OS login will be used to validate the request unless you choose to specify a different username and
password.
The awexe Commands
Using awexe commands, you can access a wide range of Applications Manager capabilities such as updating
Substitution Variables values, retrieving values from multi select prompts, and taking actions on tasks in the
Backlog.
The awexe commands are defined in the awserver_sql.dat and awserver_sqlusr.dat files located in the data
directory of the Automation Engine.
The awserver_sql.dat file includes commands for Applications Manager background processes and general user
utilities. If you or Applications Manager Consulting Services wish to add custom awexe commands, you do so by
creating the awserver_sqlusr.dat file. If you add commands to the awserver_sql.dat file, they will be overwritten
when you upgrade Applications Manager.
The Applications Manager Command Line Interface
You can access the functionality of the Explorer window with the Applications Manager command line interface.
You issue command line interface commands from the system command line or a DOS prompt on the Automation
Engine machine or an Agent machine. There are two ways to use the Applications Manager command line
interface: in command mode, or as a single function.
 Applications Manager 9.4.1

Deciding Which Utility to Use

All three utilities allow you to execute commands from either the command line or a script. awexe and the
command line interface allow you to run tasks using their own version of awrun. The code below shows an
example of each:

> awrun TEST_JOB -u SQLOPER -z s0pass

JOBID: 65975
> awexe aw_run so_job_command="TEST_JOB -q EXPRESS -v TEST_JOB_VIA_AWRUN"
so_user_name=SQLOPER password=s0pass
JOBID: 65814
> appworx run TEST_JOB -u SQLOPER -z s0pass
JOBID: 65976

When you issue command line interface commands, Applications Manager actually runs awexe commands. The
command line interface provides a wrapper to make them more accessible. The code below shows the appworx a
command line interface command and awexe node command. Both provide the same information, but appworx a
includes column titles for better readability:

> appworx a
Agent Status Last Act M/A Thds Bk Run Hld Abt Sch
PROD6 Running 00:00:40 M 9999 1 0 0 0 0
PROD6 Running 00:00:15 A 9999 1 0 0 0 0
SOLARIS9 Stopped 88 Days A 2 1 0 0 0 0
WINXP Running 00:00:31 A 1 1 0 0 0 0
APPWORX_A G 0 1 0 0 0 0
> awexe node
PROD6 Running 00:00:47 M 9999 1 0 0 0 0
PROD6 Running 00:00:22 A 9999 1 0 0 0 0
SOLARIS9 Stopped 88 Days A 2 1 0 0 0 0
WINXP Running 00:00:38 A 1 1 0 0 0 0
APPWORX_A G 0 1 0 0 0 0

As a rule of thumb, use awrun and awexe to incorporate Applications Manager functionality into your scripts
or interface Applications Manager with other applications, and the command line interface to either run single
commands from the command line or go into command mode to run a series of commands.

awrun - The Command Line API for Requesting Tasks

Using the awrun command, you can insert a row directly into the Applications Manager JOB_QUEUE table. When
you issue the command, you specify the Job, options, and any necessary arguments. While it is possible to insert
records directly into the JOB_QUEUE table using database commands, we do not recommend this approach. You
should use awrun instead.
The arguments are the values used for prompts defined for the Job. awrun also can be used to call Applications
Manager from another Windows application. For security reasons, the use of awrun is User Group controlled.
The current OS login will be used to validate the request unless you choose to specify a different username and
password.
You can also request tasks through Oracle using the awop_api.awrun procedure. For more information, see
Appendix B: awop_api.awrun - Requesting Tasks Through Oracle.
awrun Command Syntax
 Applications Manager 9.4.1

The command line syntax for awrun is:

awrun <job name>|<job number> -u <user ID> <options> <arguments>

Unless otherwise indicated below, any option not specified will default to the setting defined in the Job. The
keyword _NULL_ may be used as a missing argument placeholder.
Supported Options
The options supported by awrun are described below. You can also view this information online by entering awrun
-h at the command line.

Option Description

-a <Y/N> Stay in Queue on abort option.

Y: if the Job aborts, it stays in the Queue (Backlog).
N: if the Job aborts, it drops out of the Queue to History.

-arg <prompt value> Remaining characters are considered arguments.

-c <number> Number of copies to print when the PRINT output

function is selected.
Range 1-99

-d <date> Date on which Job should run (default = TODAY).

Format of date must be mm/dd/yyyy.

-f <output function> The Job's output function:

• LOG: Legacy setting. Should not be used unless
you need to use the Output window rather than the
Explorer window.
• PRINT: The output is printed.
• STORE: The output is not printed.

-h Used to return awrun help from the command line. Only

use this option by itself.

-hj <Y/N> Submit the task on hold:

Y, Job will be submitted on hold.
N, Job will not be submitted on hold.

-iic <run ID of Process Flow> Insert into Process Flow.

-l <Login> Login to use with Job.

-m <Job name> Name of Job to run.

-n <Job number> Job definition number.

-o <Agent> Agent to run the Job on.

-p <Output Device> The Output Device for Job output.

-pt <output option> Output option to be passed to the Output Interface.

-pr <predecessors> Specifies predecessors for the Job.

-q <Queue> Name of Queue in which to run the Job.

 Applications Manager 9.4.1

Option Description

-r <Y/N> Restart on abort option.

Y, Job will restart once if it aborts.
N, Job will not restart if it aborts.

-s <Y/N> Determines whether to use the Job's default prompts:

Y, arguments not specified will use Job's default
arguments (default = Y).
N, arguments not specified will remain undefined.

-t <time> Time at which Job should run (default = NOW).

Format of time must be HH:MM:SS (HH: 00-23).

-u <User> User/requestor name for the Job. If you use this option,
you must also specify the User's password using the -z
option.
If you do not specify a User, Applications Manager uses
the UNIX/Windows login name. However, the UNIX/
Windows user must exist as a valid User in order to
validate that the User's User Group will allow them to
run the Job.

-v <view name> Alias (or view name) for Job.

-x <max run time> Maximum time Job can run. If not completed after
this much time, the task will abort. Format must be
DDD:HH:mm.

-y <number> Priority for Job in relation to other Jobs in the same

Queue. Range 0-99. Lower number is higher priority.

-z <password> Password for User specified with the -u option.

Generally, you should not include the password in the
awrun command because the password can be read if
you run the PS command.

Notes on awrun
The '|' indicates 'and/or'. You can provide either the Job name or the Job number.
The <arguments> option is the same as 'parameters' or 'prompts'. Values entered for prompts on the Requests
window are the arguments.
The order of the awrun statements is important. You cannot specify an argument and then an option. Also, some
options and prompts can appear similar, but have uniquely different functions. For example, the date option -
d is different from the date specified in an argument. If you do not use the -m Job flag, the first value passed is
interpreted by Applications Manager to be the Job name.
For example:

awrun EXAMPLE2 -u ssmith -z abcd1234 -q BATCH -arg -c -d -e

EXAMPLE2 is interpreted as the Job name. For this to work, the Job name must come before any of the flagged
options.
 Applications Manager 9.4.1

If you want to use a Substitution Variables for an argument to an awrun task from the command line, you must
protect the '#' sign. In a UNIX shell, the '#' sign indicates a comment line, and the line is ignored. To get UNIX to
recognize the '#' sign you can protect it using one of the following formats:
• \#Subvar
• "#Subvar"
• {#Subvar}
awrun Security
For security reasons, awrun requires a username and password by default.
You can include the awrun command in a script along with environment variables that control parameters such as
Queue, Output Devices, and number of copies.
For example, including the following command in a script would run the EMPLOYEES Job against the Accounting
department, run the task through the BATCH Queue, send the output to the TEST printer, and print three copies:

awrun EMPLOYEES -u sqloper -z s0pass -m employees -q BATCH -p TEST -c 3 -arg ACCOUNTING

You might consider setting your password in a previous script, in an Applications Manager PREFIX script, or on
the command line immediately before issuing your awrun statement in order to prevent others from viewing your
password.
To set the password, you set the environment variable AWRUN_PASSWORD.
If the operating system user account is also a valid User, you do not need to enter the password.
Not Requiring Passwords for awrun
If you want to use awrun without a -z <password>, you can select the Do not require awrun passwords
Automation Engine option for the Automation Engine/Local Agent.
awrun Examples
Several examples of the awrun command are shown below.
Example 1. The command below will run the Job 'EXAMPLE1', use the 'sqloper' User and 's0pass' password,
connect to the database using Login 'ADMIN', and run in the 'BATCH' Queue. The task will appear in the Backlog
and History as 'MARCH' and the two dates will be passed as the first and second arguments.

awrun EXAMPLE1 -u sqloper -z s0pass -l ADMIN -q BATCH -v MARCH 03-01-97 03-31-97

Example 2. The command below will run the Job 'EXAMPLE2', in the 'BATCH' Queue. The -arg option tells awrun
to treat -c, -d and -e as arguments for Job 'EXAMPLE2' rather than as further options for sorun.
awrun will return an error if it is passed an object name that doesn't exist. For example, passing awrun a Job
name, Database Login name, operator name, etc. that is not already defined within Applications Manager will
cause an error (see awrun -e).

awrun -u ssmith -z abcd1234 -m EXAMPLE2 -q BATCH -arg -c -d -e

Example 3. The command below runs the EMPLOYEES Job with one argument (ACCOUNTING). The Job will
produce a report of all employees in the Accounting Department.

awrun -u sqloper -z s0pass -m employees ACCOUNTING

 Applications Manager 9.4.1

Example 4. The command below runs the INVOICE Job with one option (date) and three arguments. Notice that
the argument dates can be in any form (as specified by the program). However, the date option must be in mm/dd/
yyyy format.

awrun -u sqloper -z s0pass INVOICE -d 11/15/1998 -arg 03-01-97 _NULL_ Jan-15-1998

Specifying Rapid Automation (RA) Field Values and Prompts for awrun Requests
You can specify an RA Job field value in the following format with as many space separated XML names and
values as you wish. You can get the XML field name for a field but resting the mouse over the field name in the
client and reading the ToolTip.

awrun <RA job> <xml name>=<value>

You can specify RA prompt values in the following format.

awrun <RA job> prompt_<row number>_<column number>=<value>

Row and prompt numbers start at 0. For example, to edit prompt 3 in the GURPDED Job shown in the image
below, you would enter the following awrun command:

awrun GURPDED prompt_2_3=YOURUSER

 Applications Manager 9.4.1

awexe - Accessing Applications Manager Capabilities

Using awexe commands, you can access wide a range of Applications Manager capabilities such as updating
Substitution Variables values, retrieving values from multi select prompts, and taking actions on tasks in the
Backlog.
The awexe commands correlate with a list of options in the awserver_sql.dat and awserver_sqlusr.dat files
located in the data directory.
 Applications Manager 9.4.1

The awserver_sql.dat file includes commands for Applications Manager background processes and general user
utilities. If you or Broadcom Consulting Services wish to add custom awexe commands, do so by creating the
awserver_sqlusr.dat file. If you add commands to the awserver_sql.dat file, they will be overwritten when you
upgrade Applications Manager.
Custom awexe calls are not supported by Broadcom Support. For help creating/maintaining them, contact
Broadcom Consulting Services.
Each awexe command begins with a security number to group it into one of the following categories:
• 1000-1999: Used for Applications Manager background processes.
• 2000-2999: Utilities for the general user.
• 3000-4999: Reserved for consulting.
• 5000-9999: Used for custom definitions.
The range of numbers entered in the Awexe range field for a User determines which awexe commands are
available for that login during a UNIX/Windows session. For more information on the Awexe range field, see the
Administration Guide.
The following awexe commands can be used in your scripts or from the command line. Example code follows each
command.
awexe Command Syntax
The command syntax for awexe is:

awexe <awexe command name>|<awexe command number> <argument>=<argument values>

The '|' indicates 'and/or'. You can provide either the awexe command name or the awexe command number.
The number of arguments differs depending on the definition of the awexe call. When specifying argument values,
you can use singe quotes to specify a literal value or double quotes to specify a value to be evaluated.
Text from the awserver_sql.dat file for the awexe upd_var_value call used to update an existing static
Substitution Variables value is shown below:

1900 UPD_VAR_VALUE OTHER 1 0 OBD_CLS_COM_CONT NULL NULL

var_value,subvar # #

In the example below, the value of the #success Substitution Variables is being set to Y. First awexe
upd_var_value specifies the upd_var_value command name. Next, the Subvar=#success argument specifies
the Substitution Variables to update. Finally, the var_value=Y argument specifies the Substitution Variables's new
value.

>awexe upd_var_value subvar=#success var_value=Y

Some variables are required; others accept null values. See the awserver_sql.dat file for details.
Common awexe Commands
Common awexe commands that you may want to use in your scripts are described in the next topic.

Common awexe Commands You Can Use in Your Scripts

Common awexe commands you may want to use in your scripts or to interface Applications Manager with other
applications are described below.
The awserver_sql.dat file located in the data directory includes several commands used for Applications Manager
background processes and general user utilities. This topic documents the commands that may be useful to you
 Applications Manager 9.4.1

in your scripts or to interface Applications Manager with other applications. These commands can help you with
actions such as:
• Activating Automation Engine and Agent Debug
• Updating a Substitution Variable or Creating a New Substitution Variable
• Retrieving a Substitution Variable
• Taking Actions on Tasks
• Retrieving a Multi Select Prompt Value
• Retrieving a Multi Select Prompt Description
• Requesting Jobs and Process Flows
• Getting Process Flow Names from Component Run IDs
• Viewing a Queue Summary
• View an Agent Summary
• Starting or Stopping the Automation Engine
• Viewing Tasks in the Backlog
• Viewing Tasks in History
• Viewing an RMI and Agent Connection Summary
• Viewing a Applications Manager User Report
Each command documented below includes a format, example, and command number. The command numbers
correlate with each call's definition in the awserver_sql.dat file. For more information on a particular call, see the
awserver_sql.dat file.
Activating Automation Engine and Agent Debug
To turn on Automation Engine and Agent debug, use the awexe SCHEDULE_DEBUG call.
Format

awexe SCHEDULE_DEBUG START_TIME=<HH:mm> MINUTES=<mmm>

Example
In the example below, debug is turned on at 6:00 PM for 30 minutes.

>awexe SCHEDULE_DEBUG START_TIME=18:00 MINUTES=030

Updating a Substitution Variable or Creating a New Substitution Variable

To update an existing static Substitution Variables value, use the awexe upd_var_value call.
Format

awexe upd_var_value subvar=<subvar name> var_value=<value>

Example
In the example below, the value of the #success Substitution Variables is being set to Y.

>awexe upd_var_value subvar=#success var_value=Y

To create a new static Substitution Variables and set its value, use the awexe upd_var_value call with the flag=Y
argument.
 Applications Manager 9.4.1

Format

awexe upd_var_value subvar=<subvar name> var_value=<value> flag=Y

Example
In the example below, the #success Substitution Variables is created with the value of Y.

>awexe upd_var_value subvar=#success var_value=Y flag=Y

Command Number
1900
Retrieving a Substitution Variable
To retrieve the value of a JDBC or Oracle SQL Substitution Variables, use the awexe get_var_value call.
Format

awexe get_var_value subvar=<subvar name>

Example
In the example below, the value for the #today substitution is returned.

> awexe get_var_value subvar=#today

27-jan-09

Command Number
1901
Taking Actions on Tasks
To take actions on one or more tasks, use the awexe aw_quemgr call.
Format

awexe aw_quemgr tranmode=<letter> jobids='<space separated run_ids inside single quotes>'

so_user_name=<Applications Manager user name> password=<user password>

The following tranmode letters correspond to an action:

H-Hold task(s)R-Reset task(s)D-Delete task(s)K-Kill task(s)
Example
In the example below, User PBROWN deletes run_id 65711.00.

> awexe aw_quemgr tranmode=D jobids=65711.00 so_user_name=PBROWN password=8uwc76

Success jobids processed
 Applications Manager 9.4.1

Command Number
2001
Retrieving a Multi Select Prompt Value
To return the value(s) from a multi select prompt, use the awexe multiselect_value call.
Format

awexe multiselect_value arg_1=<reference number>

Example
In the example below, a Job included a multi select prompt that allowed a User to select one or more Applications
Manager Jobs. When the Job was requested, the prompt's value was displayed as Ref=65772. The awexe
multiselect_value call below returns the Jobs selected for the prompt.

>awexe multiselect_value arg_1=65772

10_MINUTES
20_MINUTES
7147
ABORTER
AGENT_GROUP

Command Number
2004
Retrieving a Multi Select Prompt Description
To return the description(s) from a multi select prompt, use the awexe multiselect_descr call.
Format

awexe multiselect_value arg_1=<reference number>

Example
The example below returns the descriptions of Jobs selected in a multi select prompt.

>awexe multiselect_descr arg_1=65772

10_MINUTES-Test Job
20_MINUTES-Test JOBl2
7147-Testing bug 7147
ABORTER-This will abort
AGENT_GROUP-agent Groupl

Command Number
2005
Requesting Jobs and Process Flows
To request a Job or Process Flow, use the awexe aw_run call.
 Applications Manager 9.4.1

Format

awexe aw_run so_job_command="<Job/Process Flow name and arguments>"

so_user_name=<Applications Manager user name> password=<user password>

You can type awrun -h and press Enter to view a list of awrun options.
The awexe aw_run call is equivalent to awrun. For more information, see awrun - The Command Line API for
Requesting Tasks.
Example
In the example, TEST_JOB is requested on the EXPRESS Queue with the alias TEST_JOB_VIA_AWRUN.

> awexe aw_run so_job_command="TEST_JOB -q EXPRESS -v TEST_JOB_VIA_AWRUN"

so_user_name=SQLOPER password=s0pass

Command Number
2006
Getting Process Flow Names from Component Run IDs
To view a parent Process Flow's name when you provide a Process Flow component's run ID, use the awexe
get_chain_name call.
Format

awexe get_chain_name jobid=<run ID number>

Example
An example is shown below.

> awexe get_chain_name jobid=689046

SAMPLE

Command Number
2007
Viewing a Queue Summary
To view a Queue summary, use the awexe q call.

2010 Q SELECT 1000 0 OBD_CLS_COM_CONT NULL FETCH_ROW

# result #

Example
An example is shown below.

awexe q
 Applications Manager 9.4.1

BATCH #### 7 A 50 12
EXPRESS 7 0 A 10 9
JACK 9 0 A 50 11
MONITOR #### 0 A 50 12
PRIORITY 4 0 A 40 6
QUEUE00 8 0 A 50 10
RUTH 9 0 A 50 11
Total Qs #### 7 A 12

The awexe q call returns the following columns: Queue, max threads, tasks in the Backlog, active or inactive
status, priority, and Thread Schedule sequence.
Command Number
2010
View an Agent Summary
To view an Agent summary, use the awexe node call.
Example
An example is shown below.

/home/tech6/site $ awexe node

PROD6 Running 00:00:30 M 9999 6 0 0 0 1
PROD6 Running 00:00:17 A 9999 6 0 0 0 0
SOLARIS9 Stopped 84 Days A 2 1 0 0 0 0
WINXP Running 00:01:00 A 1 1 0 0 0 0
APPWORX_A G 0 0 0 0 0 1

The awexe node call returns the following columns: Agent, status, elapsed time, Automation Engine/Agent/group,
max threads, tasks in the Backlog, running tasks, tasks on hold, aborted tasks, running scheduled tasks.
Command Number
2011
Starting or Stopping the Automation Engine
To start or stop the Applications Manager Automation Engine, use the use the awexe master command=start and
awexe master command=stop calls.
Command Number
1028
Viewing Tasks in the Backlog
To view tasks in the Backlog, use the awexe jq call.
Example
An example is shown below.

> awexe jq
65712.00 BATCH SAMPLE 01/27 15:29 HOLD PROD6
65713.00 BATCH PROMPT_EXAMPLE 01/27 15:29 STAGED_PW PROD6 JACK SAMPLE
65714.00 BATCH TEST_JOB 01/27 15:29 STAGED PROD6 JACK SAMPLE
65715.00 BATCH TEST_JOB.2A 01/27 15:29 STAGED PROD6 JACK SAMPLE
65716.00 BATCH TEST_JOB.3 01/27 15:29 STAGED_PW PROD6 JACK SAMPLE
65717.00 BATCH TEST_JOB.4 01/27 15:29 STAGED_PW PROD6 JACK SAMPLE
 Applications Manager 9.4.1

65718.00 BATCH TEST_JOB.5 01/27 15:29 STAGED_PW PROD6 JACK SAMPLE

The awexe jq call returns the following columns: run ID, Queue, Job/Process Flow/component, start date and time,
task status, Agent, parent Process Flow.
You can use the syntax awexe jq module=<ABC>% to return Jobs, Process Flows, or components with names or
aliases starting with the text entered as <ABC>.
Command Number
2012
Viewing Tasks in History
To view tasks in History, use the awexe jh call. You can specify a number of minutes to look back using the format
awexe jh minutes=<number of minutes>.

2013 JH SELECT 10000 0 OBD_CLS_COM_CONT NULL FETCH_ROW

minutes # result #

Examples
An example is shown below.

> awexe jh
65771.00 BATCH TEST_JOB 01/28 09:20 00:00:05 FINISHED TECH6

An example is shown below that specifies a number of minutes.

> awexe jh minutes=180

65771.00 BATCH TEST_JOB 01/28 09:20 00:00:05 FINISHED TECH6
65770.00 BATCH EXAMPLE_SCHEDULES 01/28 09:00 00:00:06 FINISHED
65769.00 BATCH SCHEDULES00 01/28 09:00 00:00:06 FINISHED
65768.00 BATCH EXAMPLE_SCHEDULES 01/28 08:00 00:00:06 FINISHED
65767.00 BATCH SCHEDULES00 01/28 08:00 00:00:06 FINISHED

The awexe jh call returns the following columns; run ID, Queue, Job/Process Flow/component, finished date and
time, elapsed time, task status, requestor, parent Process Flow.
Command Number
2013
Viewing an RMI and Agent Connection Summary
To view a server and Agent connection summary, use the awexe rmi_status call.
Example
An example is shown below.

> awexe rmi_status

Host IP Session Last Activity
Master n/a 28804 01/28/05 09:55:16
obiwan 200.1.1.2 0 05/28/04 15:50:18
obiwan 200.1.1.2 0 10/28/04 09:13:40
 Applications Manager 9.4.1

obiwan 200.1.1.2 28804 01/28/05 09:55:16

The awexe jh call returns the following columns: run ID, Queue, Job/Process Flow/component, finished date and
time, elapsed time, task status, requestor, parent Process Flow.
Command Number
2020
Viewing an Applications Manager User Report
To view a report of User logins, use the awexe show_users call.
Example
An example is shown below.

> awexe show_users

JIRETON 555.1.1.301 11/20/06 08:34:57 Current
BILLG 222.1.1.024 11/20/06 08:47:08 Current

The awexe show_users call returns the following columns; User, IP address, date, time, status.
Command Number
2109

AppWorx Command Line Interface - Accessing Explorer Functionality

You can access the functionality of the Explorer window with the AppWorx command line interface. You issue
command line interface commands from the system command line or a DOS prompt on the Automation Engine
machine or an Agent machine.
There are two ways to use the AppWorx command line interface: in command mode, or as a single function. An
example is shown for each executing the 'h' help command.
To use command mode, type appworx at the command line.

> appworx
AppWorx> h

To execute a single command, type appworx <command>.

> appworx h

The help command displays a list of command line functions. The command line functions are shown below.

Generic Commands
Idle agentname [Agent] Idle an agent or master
RESume agentname [Agent] Resume an agent or master
RUN module_name [options] [args] Request a module to run
STARtso agent(ALL) [Agent] Start Applications Manager processes
(Default=ALL)
STATus Process status list
STOPso agent(ALL) [Agent] Stop Applications Manager processes
 Applications Manager 9.4.1

(Default=ALL)
User Process Listing of user soport
Watchworx start|stop Start/Stop Local WatchWorx Process
Backlog Commands
Delete jobid(s) Delete selected jobids
Kill jobid(s) Kill selected jobids
HOld jobid(s) Hold selected jobids
Edit jobid Edit a jobid and its prompts
Release jobid(s) Release from Hold selected jobids
Getvar varname Retrieve Static Subvar
Setvar varname=value Set Subvar static value
JQ Job Queue Listing
JH [HISTORY=mins] Job History Listing
Agents Agent Summary
Queue Queue Summary
Palm Commands
PQ Shortened Job Queue Listing
PH [minutes] Shortened Job History Listing
PAgents Shortened Agents Summary
Other Commands
RMi Status of Rmi Server(s)
Load filename Loads file and extracts 1st field as jobids
Can be used by:
Delete, Kill, Hold, Release. (i.e. del jobids)
! {number} Re-execute command (i.e. !12)
! {command} Pipe Host Commands (i.e. !who)
{Appworxcommand} | {command} Pipe Host Commands (i.e. jq|grep BATCH)
{Appworxcommand} > {output file} Redirect output to file (i.e. user>x.dat)
HIstory Display command history
Help Display this help screen
eXit Exit command line utility
QUIt Quit command line utility

Notice that each of the command line functions is listed beginning with one to four capital letters. These are the
only required characters for the command. So, it is okay to enter Q (or Qu, Que, or Queu if you like) for Queue.
Functions are not case sensitive, so q, qu, que, queu, and queue will work just as well.
While in command mode, you can press Enter to execute the previous command again.
Assigning Users to an Exe Range
In order for Users to use the AppWorx command line interface, they must have been assigned the correct Awexe
range. If you enter 2000-2099, the User will have access to all the AppWorx command line interface functions.
However, to change any data, they will be required to supply a User name and password.

Entering Generic Commands

The generic AppWorx command line functions are used to:
• Idle and resume Automation Engines and Agents.
• Run Jobs.
• Start and stop Applications Manager processes.
• List major processes that are running.
• List all processes that are running for a User.
• Start or stop the local WatchWorx process.
Idling and Resuming Agents and Automation Engines
 Applications Manager 9.4.1

To idle an Agent or Automation Engine, type the following:

Idle agentname <agent>

To resume an Agent or Automation Engine, type the following:

RESume agentname <agent>

Example: Idling an Agent

To idle the Agent PROD-HP:

AppWorx> i PROD-HP

Example: Idling an Automation Engine

To idle the Automation Engine PROD-HP (the M specifies the Automation Engine rather than the Local Agent with
the same name):

AppWorx> idle PROD-HP M

Example: Resuming an Agent

To resume the Agent PROD-HP:

AppWorx> res prod-hp

Example: Resuming an Automation Engine

To resume the Automation Engine PROD-HP:

AppWorx> resume prod-hp

Running Jobs
To run a Job, type the following:

RUN <job name> <options> <args>

You can type 'run' and press Enter to view a list of options. The run function is equivalent to awrun. For more
information, see awrun - The Command Line API for Requesting Tasks.
Starting and Stopping Commands
 Applications Manager 9.4.1

To start an Agent and/or Automation Engine, type the following:

STARtso agent(ALL) <agent>

To stop an Agent and/or Automation Engine, type the following:

STOPso agent(ALL) <agent>

Example: Starting an Automation Engine and Agent

To start the Automation Engine and the Agent PROD-HP:

AppWorx> start PROD-HP

Example: Stopping an Automation Engine and Agent

To stop the Automation Engine and the Agent PROD-HP:

AppWorx> stop prod-hp

Example: Stopping an Agent

To stop just the Agent PROD-HP:

AppWorx> stop prod-hp agent

or:

AppWorx> stop prod-hp a

Example: Starting an Automation Engine

To start just the Automation Engine PROD-HP:

AppWorx> start prod-hp master

Example: Starting an Automation Engine and All Its Remote Agents

To start the Automation Engine and all Local and Remote Agents:

AppWorx> start
 Applications Manager 9.4.1

You will be prompted with the following question. You must type 'y' for yes.

'startoper ALL ' Are you sure? y

Example: Stopping an Automation Engine and All its Remote Agents

To stop the Automation Engine and all Local and Remote Agents:

AppWorx> stop

You will be prompted with the following question. You must type 'y' for yes.

'stopoper ALL ' Are you sure? Y

Viewing Process Statuses

To view a list of process statuses, type the following:

STATus

Example

AppWorx> stat
PROD1 Program Status Sleep Last Act Pid
PROD1 awcomm Running 0 5 days 4454
PROD1 agentserv Running 0 2 minutes 6774
PROD1 rmiserver Running 0 97 seconds 6865

Process Listing of an Applications Manager User

To view a process listing of the User, type the following:

User

Example
In this example, the User is soport.

AppWorx>user
soport 10386 10384 0 Aug 17 ? 0:00 /isa/apache/bin/httpd -d /isa/devel/soport/dev/v
soport 22401 1 0 Aug 18 ? 34:24 /isa/j2re1_3_0/bin/../bin/sparc/native_threads/java -
soport 15194 1 0 Aug 12 ? 0:04 /isa/devel/soport/dev/c/awcomm PBROWN

Starting and Stopping the WatchWorx Process

 Applications Manager 9.4.1

To start the local WatchWorx process, type the following:

Watchworx start

To stop the local WatchWorx process, type the following:

Watchworx stop

Entering Backlog Commands

Each of the Backlog AppWorx command line functions is described with examples in this topic.
The Backlog command line functions are used to:
• Change task statuses in the Backlog.
• View and edit task details and prompts.
• Get and set Substitution Variables.
• View a summary of the Backlog, History, Agents, or Queues.
If you are taking multiple actions on tasks or you want to include command line interface calls in your scripts, you
can set so_user_name and AWEXE_PASSWORD variables as shown below:

> so_user_name=SQLOPER
> AWEXE_PASSWORD=s0pass
> export so_user_name AWEXE_PASSWORD
> echo y|appworx delete 65885.00
Delete 65885.00
Are you sure? Success jobids processed
>

Deleting Tasks in the Backlog

To delete selected run_ids in the Backlog, type the following:

Delete <run_id(s)>

Example

AppWorx> del 680942

You will be prompted to enter a User Id and password as shown below:

You have requested a command which requires a user_id and password before execution
Userid (soport)>sqloper
Password ()>
 Applications Manager 9.4.1

When you delete the run_id, you will see the following message:

Success 1 jobids processed

Killing Tasks in the Backlog

To kill selected run_ids in the Backlog, type the following:

Kill <run_id(s)>

Putting Tasks On Hold in the Backlog

To hold selected run IDs in the Backlog, type the following:

HOld <run_id(s)>

Example

AppWorx> hold 680941 680940

When you put the run_id on hold, you will see the following message:

Success 2 jobids processed

Viewing and Editing Task Details and Prompts

To view task details for a selected run_id in the Backlog or History, type the following:

Edit <run_id>

Applications Manager will display the task details for the Job/Process Flow. You can change the task's parameters
in the Backlog before the task runs, or if it aborts or is killed.
Example
To edit general task details:
1. Issue the edit command for the run_id you wish to edit. Be sure to enter the entire run_id, including the decimal
value.

> e 3141.01

Detail Summary for job 3141.01 TEST_JOB

Job TEST_JOB 1 Max Run Time 1800
User SQLOPER 2 Priority 50
Job ID 3141.01 3 Login
Chain Name 4 Queue BATCH
 Applications Manager 9.4.1

Chain Order 5 Agent PROD1

Request Date 06/23/03 13:20:46 6 Start Date
06/23/03 13:20:39
Started 06/23/03 13:21:51 7 Printer TEST
Ended 8 Print Option
Status KILLED 9 Output STORE
Process ID 48046 10 Copies 1
11 Restart N

2. Enter the number for the task detail you wish to edit, or enter P to edit a prompt.
The number 2 is entered in the example below to change the task's priority.

Enter item number or P - Prompts, Q - Quit, <cr> to exit with no changes >2

3. Enter a new value for the task detail.

The new priority of 30 is entered below.

Change priority for job 3141.01 TEST_JOB

priority = [50] (<cr> to accept)> 80
priority = [30] (<cr> to accept)>

4. Hit enter again to accept the displayed value.

Applications Manager displays the task details with the new value. The edited task detail includes an * to show
that a value has been changed, but not yet saved.

Detail Summary for job 3141.01 TEST_JOB

Module TEST_JOB 1 Max Run Time 1800
User SQLOPER 2* Priority 30
Job ID 3141.01 3 Login
Chain Name 4 Queue BATCH
Chain Order 5 Agent PROD1
Request Date 06/23/03 13:20:46 6 Start Date
06/23/03 13:20:39
Started 06/23/03 13:21:51 7 Printer TEST
Ended 8 Print Option
Status KILLED 9 Output STORE
Process ID 48046 10 Copies 1
11 Restart N
Changed priority [50] to [30]
Enter item number, S - Save, P - Prompts, Q - Quit >

Prompts for job 3141.01 TEST_JOB

Ord Descr Value
1 Sleep Time 10
Enter Prompt Number to edit (<cr> to accept) >1
1 Sleep Time [10]
?300
 Applications Manager 9.4.1

Prompts for job 3141.01 TEST_JOB

Ord Descr Value
1 Sleep Time * 300
Enter Prompt Number to edit (<cr> to accept) >
Job info saved
AppWorx>

5. To edit prompts, enter P as shown below. Then select a prompt number and value. Pressing Enter again takes
you back to the Detail Summary.

Enter item number or P - Prompts, Q - Quit, <cr> to exit with no changes >p

6. Edit as many task details/prompt values as you wish. When you are done editing task details, enter an S to
save.

Enter item number, S - Save, P - Prompts, Q - Quit >s

Resetting Tasks in the Backlog

To release from Hold selected run_ids in the Backlog, type the following:

Release <run_id(s)>

Retrieving Static Substitution Variables

To view the value of a static Substitution Variables, type:

Getvar <subvar name>

Example
This example returns the value of the Subvar #company_name.

AppWorx> G #company_name
ABC Corporation

Setting Static Substitution Variables

To set the value of a static Substitution Variables, type:

Setvar <varname>=<value>

Example
 Applications Manager 9.4.1

This example sets the value of the #company_name Substitution Variables to ABC Inc.

AppWorx> S #company_name=ABC Inc.

AppWorx> G #company_name
ABC Inc.

Viewing Tasks in the Backlog

To view a list of tasks in the Backlog, type the following:

JQ

Example

AppWorx> jq|grep M21

M21 680941.00 BATCH M21 08/19 10:07 QUEUE WAIT PBROWN PROGRAMMERLOAD

Viewing Tasks in History

To view a list of tasks in History, type the following:

JH

Viewing an Agent Summary

To view an Agent summary, type the following:

Agents

Example

AppWorx> a
Agent Status Last Act M/A Thds Bk Run Hld Abt Sch
PROD-HP Stopped 00:40:04 M 99 34 0 11 0 27
APPS Running 00:00:50 A 99 0 0 0 0 0
PROD-HP Stopped 00:40:39 A 99 34 0 11 0 27
SUN27DEV Running 00:00:23 A 99 0 0 0 0 0
ALL G 0 0 0 0 0 0
OAEGROUP G 0 0 0 0 0 0

Viewing a Queue Summary

 Applications Manager 9.4.1

To view a Queue summary, type the following:

Queue

Example

AppWorx> q
Queue Thds Bk Stat Pri Sched
BATCH 999 72 A 50 59
BURT_AND_E 1 0 A 49 1
EXPRESS 0 0 I 10 99
GIANG 1 0 A 50 1
MONITOR 99 0 A 50 99
NEWQUEUE 999 0 A 59 59
PRIORITY 1 0 A 40 1
Total Qs 99 72 A 99

Entering PDA Commands

PDA versions of three Backlog Commands allow you to use a PDA to view a summary of:
• Tasks in the Backlog.
• Records in History.
• Agents.
Viewing Tasks in the Backlog with a PDA
To view a list of tasks in the Backlog using a PDA, type the following:

PQ

Example

AppWorx> PQ
Module Status Jobid
PREDECESSOR_DEMO INITIATED 148171
QA_DAYS INITIATED 154167
TIMING INITIATED 154007
TIMING INITIATED 154214
REPORT2 QUEUE WAIT 153928
REPORT8 PRED WAIT 153945

Viewing Records in History with a PDA

To view a list of tasks in History using a PDA, type the following:

PH
 Applications Manager 9.4.1

Viewing an Agent Summary with a PDA

To view an Agent summary using a PDA, type the following:

PA

Example

AppWorx> pa
Agent Status M/A Bk Run Hld Abt Sch
SUN26X Running M 36 0 10 5 12
SUN27DEV Running A 0 0 0 2 0
SUN26X Running A 32 0 9 1 12
OAE Stopped A 0 0 0 0 0
ALL G 2 0 0 1 0

Entering Other Commands

The other AppWorx command line functions are used to:
• View RMI connections.
• Load filenames (to execute commands).
• Re-execute commands.
• Execute host commands.
• Pipe host commands.
• Display a command history.
• View the AppWorx Command Line help.
• Exit the AppWorx command mode.
Viewing RMI Connections
To view the host name, IP address, session ID, and last activity for each RMI connection, type rmi.
Example

AppWorx> rmi
Host IP Session Last Activity
Master 200.1.1.50 6044522 06/20/03 15:46:06
sun26.am.com 200.1.1.50 6044522 06/20/03 15:46:06
gnguyen 200.1.1.246 0 06/20/03 14:55:17
am-rwf40zl 200.1.1.242 0 06/20/03 14:14:06
the-udddpt6jhh9 12.229.157.166 0 06/07/03 12:09:57
rtalkov-lp 4.62.176.136 0 06/07/03 10:08:29
AppWorx>

Loading a File
To load a file from AppWorx command mode, type:

Load <file name>

 Applications Manager 9.4.1

Example
This example shows how the Load command can store run IDs in a file. Below the jq|grep SHIP command is
used to find all the Jobs in the Backlog whose name contains 'SKIP'. The same command is entered again, this
time with >xx at the end to redirect the output to the file xx. Next, load xx is entered to retrieve the list of run IDs.
Then del jobids is entered to delete the run_ids. A user name and password must also be provided. If you want
to use something like this in a script, you can set so_user_name and AWEXE_PASSWORD variables. For more
information, see Entering Backlog Commands.

AppWorx> jq|grep SKIP

Jobid Queue Module Start Date Status Agent Requestor Chain
683549.00 BATCH SKIPS_MOND09/13 00:30 Monday PBROWN QA_DAYS
683550.00 BATCH SKIPS_TUES09/13 00:30 Tuesday PBROWN QA_DAYS
683551.00 BATCH SKIPS_WEDN09/13 00:30 Wednesday PBROWN QA_DAYS
683552.00 BATCH SKIPS_THUR09/13 00:30 Thursday PBROWN QA_DAYS
683553.00 BATCH SKIPS_SATU09/13 00:30 Saturday PBROWN QA_DAYS
683554.00 BATCH SKIPS_SUND09/13 00:30 Sunday PBROWN QA_DAYS
AppWorx> jq|grep SKIP>xx
Jobid Queue Module Start Date Status Agent Requestor Chain
AppWorx> load xx
jobids= 683549.00 683550.00 683551.00 683552.00 683553.00 683554.00
AppWorx> del jobids
You have requested a command that requires a user id and
password before execution
User id [soport]
Password []
Delete 683549.00 683550.00 683551.00 683552.00 683553.00 683554.00
Are you sure?y

Running a Host Command

To run a host command from AppWorx command mode, simply type:

!<command>

Example
To identify Users currently logged in:

AppWorx> !who

Displaying a Command History and Re-Executing Commands

To display a history of commands, type:

hi
 Applications Manager 9.4.1

Example

AppWorx> hi
1 jh
2 jq
3 jq|grep INIT
4 del 682255
5 hi

To re-execute a command, type:

!<number>

Example

AppWorx> !3 re-executing: jq|grep INIT

Jobid Queue Module Start Date Status Agent Requestor Chain
682253.00 BATCH QA_DAYS 08/31 00:31 INITIATED PROD1
682254.00 BATCH QA_FLOWS 08/31 00:31 INITIATED PROD1 SQLOPER
682281.00 BATCH QA_DAYS 08/31 00:31 INITIATED PROD1 SQLOPER QA_FLOW
682308.00 BATCH SCHED-TIME08/31 05:00 INITIATED PROD1
682309.00 BATCH QA_DAYS 08/31 05:00 INITIATED PROD1 TIME_ZONE_TEST

Piping Host Commands

To connect a host command to an AppWorx command function, type a pipe symbol '|'.
Example
To search for Jobs in the Backlog, which are running on the BATCH Queue.

AppWorx> jq|grep BATCH

Redirecting Output to a File

To redirect output to a file, use the '>' symbol.
Example

user>x.dat

Exiting the AppWorx Command Line Interface

To exit AppWorx Command Line Interface, type eXit or QUIt.

Program Type Descriptions

The AWSQLP Program Type scripts are the ones most commonly used by most Applications Manager users. The
SOCOBOL Program Type script demonstrates several complex features. The SUSOSHUTP Program Type script is
commonly used to shutdown Applications Manager and allow for database backups.
 Applications Manager 9.4.1

The most commonly used Program Type scripts are:

• AWSQLP
• SOCOBOL
• SUSOSHUTP
• AWJAVA
These scripts are described in this chapter.
Applications Manager ships with several predefined Program Types and corresponding Program Type scripts. You
can copy and/or create new ones as needed. Applications Manager also ships with a number of Program Type
scripts (in the exec directory) that are not linked to Program Types. You can create Program Types to link to these
scripts.
Applications Manager interface scripts are available for the most popular enterprise applications, and Applications
Manager Consulting services can create custom scripts for almost any application.
Caution Against Modifying Existing Scripts
Applications Manager strongly recommends that you do not modify the default Program Types and matching
Program Type scripts that ship with Applications Manager. If you need to upgrade Applications Manager, the
default Program Types and scripts will be overwritten.
If you want to modify the Program Types, create new ones instead. If you want to change the Program Type scripts,
make copies and modify the copies.

AWSQLP
A Program Type launches a Program Type script that supports the Program Type. In the example below, the SQLP
Program Type script launches from the sql directory. The AWSQLP Program Type script ships with Applications
Manager and can be used as the basis for creating customized Program Types to meet the needs of your
organization.
UNIX Program Type Script
Below is a listing of the UNIX SQL*Plus Program Type script that ships with Applications Manager. Line numbers
have been added for reference purposes only, and do not appear in the actual script.

001| :
| #!/bin/sh
|
| #copyright 2007 by Automic Software GmbH
005| # $Header: EXEC-SQLP,v 1.1 96/01/22 09:42:26 soport Exp $
|#
| echo PATH Is
| echo $PATH
| if [ "$DEBUG" = "YES" ]; then
010| env
| set -x
| echo "in $0"
| fi
| if [ -f $program.sql ]; then
015| err=0
| else
| echo "file $program.sql does not exist"
| exit 1
| fi
020| echo sqlp `date`
| echo $ORACLE_PATH
| echo sqlplus -s @$program A$seq_no.lis $argu
| echo "define so_outfile=A$seq_no.lis" >> $par
 Applications Manager 9.4.1

| echo start $program >> $par

025| logtest=login.$$
| echo "$login
| spool $logtest
| prompt got it
| spool off
030| start $par A$seq_no.lis $argu
| "|sqlplus -s
| err=$?
| if [ -f $logtest ]; then
| rm $logtest
035| else
| echo Could not login to sqlplus
| err=1
| fi
| echo sqlp `date`
040| if [ -f A$seq_no.lis ]; then
| mv A$seq_no.lis $file
| fi
| $AW_HOME/exec/FILESIZE $file $err
| err=$?
045| exit $err

The key elements of the script are described below.

Lines Description

7-8 Echoes information into the system log (in this case
showing the PATH variable).

9-12 Checks if DEBUG is set (DEBUG is set in BODY.bat).

14 Checks if Program exists. If not, err=1.

23-24 Sets up output capturing and identifies the program to

be run. Line 23 echoes the command line passed to
SQL*Plus. Line 24 calls the actual command line.

26-31 Logs into SQL*Plus, runs the program, and captures the
output.

43 If the file exists, runs the FILESIZE script. This script

registers the output (i.e. creates an entry on the Output
Files tab and associates the output listing with a file).

32, 44-45 Captures and passes the return code back to

Applications Manager.

Windows Program Type Script

The Windows sqlp Program Type script that ships with Applications Manager is shown below.
Program Type Script

1 |if Not "%DEBUG%" == "YES" goto notdebug

| set
 Applications Manager 9.4.1

| echo on
| echo in %0
5 |:notdebug
|if exist %program%.sql goto exists
|echo "output file %program%.sql does not exist"
|set err=1
|goto end_of_it
10|:exists
|echo in %0
|echo plus31 -s @%program% A%seq_no%.lis %argu%
|set err=0
|echo define so_outfile=A%seq_no%.lis >> %par%
15|echo start %program% >> %par%
|echo quit >> %par%
|SET sqlplus=d:\ORANT\BIN\plus80.exe
18|echo %AW_HOME%\c\ntspawn "%sqlplus% -s %db_login%/passwd
@%PAR% A%seq_no%.lis "
19|call %AW_HOME%\c\ntspawn "%sqlplus% -s %LOGIN% @%PAR%
A%seq_no%.lis "
20|if errorlevel 1 set err=1
|if exist %file% del %file%
|if exist A%seq_no%.lis move A%seq_no%.lis %file%
|if not exist %file% echo no output from %module%
|if exist %file% call PRINTEM
25|:end_of_it

Explanation of the Script

The key elements of the script are described below.

Lines Description

1-5 Checks to see if DEBUG is set (DEBUG is generally set

in BODY.bat).

6-7 Checks if Program exists. If not, err=1.

11 Writes output to log file.

12-15 Shows command line and arguments, then passes

them to the %par%.

17 Sets SQL*Plus execution interpreter.

18-19 Line 18 echoes the commands passed to SQL*Plus.

Line 19 calls the actual command line.

20 Checks error log from SQL*Plus. If SQL*Plus returns an

error, set err=1. This ensures that the error is passed
back to Applications Manager.

21-22 Deletes any %file%. If output from this current

task exists, renames it A%seq_no%.lis%file%.
Assigns a unique file name using the Applications
Manager%seq_no%.
 Applications Manager 9.4.1

Lines Description

24 If the file exists, runs the PRINTEM script. This script

registers the output (i.e. creates an entry on the Output
Files tab and associates output listing with a file).

SOCOBOL
The SOCOBOL UNIX Program Type is used to run COBOL programs. COBOL programs can have three
requirements. They can:
• Require environment variables to be set for output files.
• Require environment variables to be set for other values.
• Accept command line arguments.
The SOCOBOL Program Type allows for these three requirements by accepting a special set of prompts.
The SOCOBOL Program Type, however, is not initially defined within Applications Manager. You must set up the
Program Type yourself. The parameters for setting up the Program Type are listed below.

Parameter Value

Type SOCOBOL

Command Path /exec

Description COBOL programs

Param format #d

Default varname not applicable

File extension as applicable

Host command SOCOBOL

Program Type Script

$ cat -n SOCOBOL
1
2 :
3 #!/bin/sh
4 # Created by Automic Software GmbH
5 #Copyright 2007 Automic Software GmbH
6 # $Header: EXEC-SOCOBOL,v 1.1 96/01/22 09:41:25 soport Exp $
7 #
8 # General format for prompts for cobol job
9 # Prompt
10 # 1 (t) Total number of environment Variables to be set
11 # 2 (N) Number of Env Variables with output filenames
12 # 3..N+2 variable=output_file_name(s)
13 # N+3..t+2 variable=value
14 # t+3.. Standard input lines as required
15 #
16 # You will also need to setup a new command type
17 # generally the same name as this filename
18 # don't forget extension and user #v for format
19 i=0
 Applications Manager 9.4.1

20 lines=`cat $par|wc -l`

21 save_file=$file
22 export='export '
23 par1=$par'1'
24 par2=$par'2'
25 par3=$par'3'
26 touch $par1
27 touch $par2
28 touch $par3
29 cat $par|while read line
30 do
31 i=`expr $i + 1`
32 if [ $i -eq 1 ]; then
33 total=$line
34 max=`expr $line + 2`
35 err=$?
36 if [ $err -ne 0 ]; then
37 exit $err
38 fi
39 elif [ $i -eq 2 ]; then
40 out=$line
41 maxout=`expr $line + 2`
42 if [ $out -gt $total ]; then
43 echo "Output files number is greater than number of envs $out vs
$total"
44 exit 1
45 fi
46 elif [ $i -le $maxout ]; then
47 var=`echo $line|awk '{{ FS = "="}{ print $1}}'`
48 file=`echo $line|awk '{{ FS = "="}{ print $2}}'`
49 bigline=$bigline$line';'
50 export=$export$var' '
51 echo $file >>$par3
52 elif [ $i -le $max ]; then
53 var=`echo $line|awk '{{ FS = "="}{ print $1}}'`
54 bigline=$bigline$line';'
55 export=$export$var' '
56 else
57 echo $line >>$par1
58 fi
59 if [ $i -eq $lines ]; then
60 echo $bigline$export >$par2
61 fi
62 done
63 eval `cat $par2`
64 err=$?
65 if [ $err -ne 0 ]; then
66 exit $err
67 fi
68 cat $par1|rstora $program
69 err=$?
70 i=0
 Applications Manager 9.4.1

71 cat $par3|while read filename

72 do
73 i=`expr $i + 1`
74 if [ -f $filename ]; then
75 echo $filename|grep '/' >/dev/null
76 status=$?
77 if [ $status -eq 0 ]; then
78 filename=$save_file'.'$count
79 fi
80 file=$filename
81 export file
82 $AW_HOME/exec/FILESIZE $file $err
83 else
84 echo "Could not find output file # $i - '$filename'"
85 fi
86 done
87 if [ "$CLEAN" = "YES" ]; then
88 rm $par1 $par2 $par3
89 fi
90 exit $

The Host command entry may need to be changed for certain COBOL environments—see the note on changing
the SOCOBOL Program Type script at the end of the Program Type Script section below.
Format for SOCOBOL Job Prompts
If you create an Applications Manager Job to run a COBOL program, you should use the format for the prompts
shown below. COBOL programs will not run correctly (or at all) if the prompts are not defined correctly.

Prompt Description

1 (t) Total number of prompts that will set environment

variables

2 (N) Number of prompts that will specify output filename

environment variables

3...N+2 Output environment variable(s) and file name(s)

N+3...t+2 Other environment variable(s)

t+3... Command line argument(s)

Program Type Script

The Program Type script that runs COBOL programs is SOCOBOL. It is located in the $AW_HOME/exec directory.
The script's primary behaviors are to:
• Process the prompts for each SOCOBOL task.
• Set up any environment variables specified for the task.
• Run the COBOL program with its specified command line arguments.
• Register the output from any output files.
If you understand UNIX shell scripts, it may be useful for you to examine the SOCOBOL script to increase your
understanding of how it behaves.
You may need to change the SOCOBOL script to use a different command for running COBOL programs than the
rstora command (shown on line 68 in the script above). To do so, copy the $AW_HOME/exec/SOCOBOL script
to another name (e.g. SOCOBOLMF for MicroFocus COBOL) and alter the new script by replacing rstora with
 Applications Manager 9.4.1

the appropriate command for your COBOL environment (e.g.: runcob). You may also want to add a path. In some
cases, rstora may need to be removed completely.
Do not modify the SOCOBOL script itself because it will be overwritten when you next upgrade, eliminating any
changes you have made. Modify a copy instead. Also note that if you use a script other than SOCOBOL to run your
COBOL tasks, you will need to change the Host command entry for your SOCOBOL Program Type definition to
match your new script (see the SOCOBOL Program Type Parameters section below).
When you create a Program Type script, be sure to give Applications Manager execute privileges for the script by
issuing the chmod 700 script_name command.
Program Type Parameters
The Program Type parameters for the SOCOBOL Program Type script are listed below.

Parameter Value

Type SOCOBOL

Command Path /cobol

Description Runs COBOL Programs

Param format #d

Default varname not applicable

File extension none

Host command SOCOBOL

You can use the Command Path field to define the subdirectory containing COBOL programs. The Command
Path entry is combined with the directory specified in the Library to provide a full path where the Program Type will
look for COBOL programs. The Command Path field is optional.
Job Prompts Example
Imagine you have a COBOL program that:
• Generates two output files whose names should be found in the environment variables OUT1 and OUT2.
• Requires three environment variables to be set (Flag1, Flag2 and Flag3).
• Requires one command line argument (a start date in dd-MMM-yy format).
The eight prompts for the Job would be defined as follows:

Prompt Description Data Type Default Value

Total number of environment Number 5

variables:

Number of output file environment Number 2

variables:

Enter environment variable and first Character OUT1=file1.out

output file:

Enter environment variable and Character OUT2=file2.out

second output file:

Enter environment variable and first Character Flag1=yes

flag setting:

Enter environment variable and Character Flag2=no

second flag setting:
 Applications Manager 9.4.1

Prompt Description Data Type Default Value

Enter environment variable and third Character Flag3=yes

flag setting:

Enter start date (dd-MMM-yy): Date 01-JAN-96

There is no need or requirement to fill in the Variable Name field for any of the above prompts.
$par
The $par variable in the shell script is set by Applications Manager. It is the name of the file holding information
from the Job's prompts. The $par file would look as follows for the SOCOBOL Job in this example.

5
2
OUT1=file1.out
OUT2=file2.out
Flag1=yes
Flag2=no
Flag3=yes
01-JAN-96

The SOCOBOL Program Type script uses the first two prompt values to process the subsequent prompts correctly.
These values and the order of the remaining prompts are therefore very important.
System Output
The system output file (o4841 in this case) for the example 8-prompt COBOL Job is shown below.
The information about this run of the Job is presented at the beginning of the file and the contents of the parameter
file ($par) are shown under the heading 'parameter file'. Also note the PRINTEM statements at the bottom of
the output showing the two files file1.out and file2.out (the two output filenames specified in the third and fourth
prompts) being registered as output.

Started
Process Id is 2797 on Mon Sep 23 09:56:32 EDT 1996
source SOCOBOL program /apps/am/cobol/prog1
Operator DEFAULT
application COBOL module COBOL_1 job_number 57
jobid 27627
batch_home /apps/am output /apps/am/out
rpf_options printer TEST
app_path /apps/am
file b.4841 command_dir /cobol copies 1 user SQLOPER
function LOG log run Y output required N
db_type ORACLE net_connect

parameter file
5
2
OUT1=file1.out
OUT2=file2.out
Flag1=yes
Flag2=no
 Applications Manager 9.4.1

Flag3=yes
01-JAN-96
PRINTEM Mon Sep 23 09:56:35 EDT 1996
file move and stored as file1.out in /apps/am/out
No printer type specified - using ANY
PRINTEM Mon Sep 23 09:56:37 EDT 1996
file move and stored as file2.out in /apps/am/out
No printer type specified - using ANY
end of /apps/am/exec/BODY status 0
Finished on Mon Sep 23 09:56:37 EDT 1996

SHUTDOWN
The SHUTDOWN UNIX Program Type was designed to let you run backups with Applications Manager. The
Program Type shuts down Applications Manager, runs the specified program, then restarts Applications Manager.
This sequence of events is illustrated below.

The table below describes what happens at each point in time shown above.

Time Point Description

0 Applications Manager is running.

1 Applications Manager starts the SHUTDOWN task

which runs the SUSOSHUT Program Type script.

2 SUSOSHUT stops Applications Manager.

3 SUSOSHUT starts its program script and waits for the

program script to finish. A typical program script may
shut down the database, run a backup program, then
restart the database.

4 The program script finishes and the SUSOSHUT script

can now issue additional commands.

5 SUSOSHUT restarts Applications Manager.

6 The SUSOSHUT task is finished and Applications

Manager moves the record of the completed task to
History.

Program Type Parameters

The SUSOSHUT Program Type parameters are listed below.
 Applications Manager 9.4.1

Parameter Value

Type SUSOSHUT

Command Path /exec

Description Database Shutdown

Param format #d

Default varname not applicable

File extension none

Host command SUSOSHUT

Program Type Script

$ cat -n SUSOSHUT
1 #copyright 1993-2006 by Automic Software GmbH
2 # $Date: 2008-05-31 15:31:22 -0700 (Sat, 31 May 2008) $ $Author: kak $ $Rev: 20676 $
3 echo In $0
4 if [ -f $AW_HOME/c/callscript ]
5 then
6 $AW_HOME/c/callscript $SQLOPER_HOME/bin/stopso all
7 else
8 $SQLOPER_HOME/bin/stopso all
9 fi
10 arg=`$SQLOPER_HOME/exec/ONELINE $par`
11 echo Switching to user
12 echo Running $SQLOPER_HOME/c/SURUN -user $program $arg
13 $SQLOPER_HOME/c/SURUN -user $program $arg
14 err=$?
15 if [ -f $AW_HOME/c/callscript ]
16 then
17 $AW_HOME/c/callscript $SQLOPER_HOME/bin/startso all
18 else
19 $SQLOPER_HOME/bin/startso all
20 fi
21 exit $err

Explanation of the Script

The key elements of the script are described below.

Lines Description

6, 8 Stops the Automation Engine and Agent processes

10 Arranges arguments on a single line

12 Runs the specified program with the user of the script

(usually a backup)

14 Captures errors
 Applications Manager 9.4.1

Lines Description

17, 19 Starts the Automation Engine and Agent processes

AWJAVA
The AWJAVA Program Type is designed to run Java applications.
UNIX Program Type Script

1 if [ -f $SQLOPER_HOME/debug/AWJAVA ]; then
2 echo Debug On
3 set -x
4 fi
5 cd $app_path
6 if [ -f CLASSPATH ]; then
7 . ./CLASSPATH
8 else
9 . CLASSPATH
10 fi
11 if [ -f $SQLOPER_HOME/debug/AWJAVA ]; then
12 echo $CLASSPATH
13 fi
14 echo java $command `$SQLOPER_HOME/exec/ONELINE $so_par`
15 java $command `$SQLOPER_HOME/exec/ONELINE $so_par`

Explanation of the Script

The key elements of the script are described below.

Lines Description

1-4, 11-13 Signifies that debug information should be written to

the task log when a file named awjava exists in the
Applications Managerdebug directory.

5 Changes the directory to the Library path of the Job.

6-10 Determines whether the to use specified classpath if -f

<classpath> is called or the current location if it is not.

14 Writes the Java command to the task log.

15 Issues the Java command.

Sending and Retrieving JMS Messages

The Applications Manager Java Message Service (JMS) solution is an add-on product you can purchase for
Applications Manager. The JMS solution allows you to develop business applications that asynchronously send
JMS messages to Queues or topics. It defines a common enterprise messaging API that is designed to be easily
and efficiently supported by a wide range of enterprise messaging products. In Applications Manager, you can send
JMS messages with conditions and retrieve messages from other applications as Applications Manager Subvars.
Sending JMS Messages
To send JMS messages with Applications Manager, you:
• Create a JMS Login object to log into the JMS server. For more information, see Creating JMS Logins.
 Applications Manager 9.4.1

• Define Applications Manager conditions that use the JMS Login you create and detail the JMS command. For
more information, see Defining JMS Messages with Conditions.
Retrieving JMS Values as Subvar Values
To retrieve JMS messages with Applications Manager, you:
• Create a JMS Login object to accept messages from other applications. For more information, see Creating
JMS Logins.
• Assign the JMS Login to the Applications Manager Automation Engine. For more information, see Assigning the
JMS Login to the Automation Engine.
• Use the following message format in the applications you wish to set Applications Manager Subvars for:

<message>
<command>setsubvar</command>
<varname>#jmsvarname</varname>
<value>value set by external process</value>
</message>

Creating JMS Logins

You define JMS Logins to:
• Log into a JMS server to send JMS messages with Applications Manager conditions.
• Allow Applications Manager to accept JMS messages from other applications.
Using JMS Logins, you have the option of defining a user name and password for the JMS server and/or queue.
 Applications Manager 9.4.1

Creating a JMS Login

To create a JMS Login:
1. From the Logins Selector window, click New.
For information on using selector windows, see Adding, Editing, and Deleting Applications Manager Objects.
Applications Manager opens the Select Login Type window shown above.
2. Select the JMS Login type and click OK.
Applications Manager opens the Logins window for the JMS Login.
3. Give the JMS Login a name.
4. Fill in the standard fields to define your JMS Login. For more information, see your JMS documentation.
Using a Different .jar File and Class Name
 Applications Manager 9.4.1

If your implementation of JMS uses a different .jar file and class name than the one Applications Manager ships
with, enter it in the JMS factory class field and put the .jar file in the web/classes directory. You will need to stop
and restart the Automation Engine.
Before starting or stopping processes, you must set the correct environment by doing the following:
1. Go to the $AW_HOME/site directory (%AW_HOME%\site for Windows).
2. For UNIX, issue the following command:

. sosite

If you get an sosite not found error, try this command:

. ./sosite

For Windows, issue the following command:

sosite

After issuing the command, you should be returned to the command prompt.
3. Stop and restart the Automation Engine with the following commands:

stopso
startso

Defining JMS Messages with Conditions

You can define Applications Manager conditions that send text-based JMS messages including XML messages.
Conditions can be defined for Jobs, Process Flows, and Process Flow components.
 Applications Manager 9.4.1

Procedure
To send a JMS message with a condition:
1. Define a condition with SEND JMS MESSAGE as its condition action.
2. Click the Details button to define the condition details.
 Applications Manager 9.4.1

Applications Manager opens a window where you can define the JMS message details shown above.
3. Fill in fields in the Jms properties box on the left side of the window.
These JMS properties, along with any JMS User properties, will define the header for the JMS message.
The fields in the Jms properties box are standard JMS properties. For more information, see your JMS
documentation.
4. Optionally add one or more custom properties in the Jms user properties box on the right side of the window.
You add a JMS user property by entering values in the Jms user properties add box and clicking Add
property.
Applications Manager adds the user property to the table above. You can edit a user property by highlighting it
in the table and updating values. You can delete a JMS user property by highlighting it and clicking Delete.
5. Enter the message body in the JMS message field at the bottom of the screen. This field accepts:
• Plain text.
• XML tags.
• Applications Manager Subvars and Replacement Values.
6. Select the JMS Login for the message.
7. Click OK to save and close the window.

Assigning the JMS Login to the Automation Engine

In order to allow Applications Manager to accept JMS messages from other applications and set them as
Applications Manager Subvars, you must assign a JMS Login you create to the Automation Engine in the JMS
Login field on the Automation Engine Options tab as shown below.

To set Applications Manager Subvars, you must also use the following message format in the applications:

<message>
<command>setsubvar</command>
 Applications Manager 9.4.1

<varname>#jmsvarname</varname>
<value>value set by external process</value>
</message>

Appendix A: Regular Expression Tables

UNIX regular expressions comprise a powerful pattern matching language. In Applications Manager, regular
expressions are allowed in Search fields on the administration selection windows and when defining file
associations.
By default, searches assume that:
• All expressions are assumed to start with '^' unless they start with a '.*'.
• All expressions are assumed to end with '.*' unless they actually end with a '$'.
Example regular expressions are shown below. They are followed by the full syntax accepted by regular
expressions.
Example Regular Expressions
Some quick examples of regular expression searches are listed below:

To search for: Use the following:

A single character wild card .

A multiple character wild card .*

All objects which start with M M (same as ^M.* or M.*)

All objects which end with M .*M$

All objects which contain -TUE- .*-TUE- (same as .*-TUE-.*)

All objects in which second letter is A .A (same as .A.*)

All objects which have the second to last letter A .*A.$

All objects which start with 'SET' or with 'PROD' set|^prod (same as typing ^set.*|^prod.*)

Characters

Character Description

unicodeChar Matches any identical Unicode character

\ Used to quote a meta-character (like '*')

\\ Matches a single '\' character

\0nnn Matches a given octal character

\xhh Matches a given 8-bit hexadecimal character

\\uhhhh Matches a given 16-bit hexadecimal character

\t Matches an ASCII tab character

\n Matches an ASCII newline character

\r Matches an ASCII return character

 Applications Manager 9.4.1

Character Description

\f Matches an ASCII form feed character

Character Classes

Class Description

[abc] Simple character class

[a-zA-Z] Character class with ranges

[^abc] Negated character class

Standard POSIX Character Classes

Class Description

[:alnum:] Alphanumeric characters

[:alpha:] Alphabetic characters

[:blank:] Space and tab characters

[:cntrl:] Control characters

[:digit:] Numeric characters

[:graph:] Characters that are printable and are also visible. A

space is printable, but not visible, while an 'a' is both.

[:lower:] Lower-case alphabetic characters

[:print:] Printable characters (characters that are not control

characters)

[:punct:] Punctuation characters (characters that are not letter,

digits, control characters, or space characters)

[:space:] Space characters (such as space and formfeed to name

a few)

[:upper:] Upper-case alphabetic characters

[:xdigit:] Characters that are hexadecimal digits

Non-Standard POSIX-Style Character Classes

Class Description

[:javastart:] Start of a Java identifier

[:javapart:] Part of a Java identifier

Predefined Classes

Class Description

. Matches any character other than newline

\w Matches a 'word' character (alphanumeric plus '_')

 Applications Manager 9.4.1

Class Description

\W Matches a non-word character

\s Matches a white space character

\S Matches a non-white space character

\d Matches a digit character

\D Matches a non-digit character

Boundary Matchers

Match Description

^ Matches only at the beginning of a line

$ Matches only at the end of a line

\b Matches only at a word boundary

\B Matches only at a non-word boundary

Greedy Closures

Closure Description

A* Matches A 0 or more times (greedy)

A+ Matches A 1 or more times (greedy)

A? Matches A 1 or 0 times (greedy)

A{n} Matches A exactly n times (greedy)

A{n,} Matches A at least n times (greedy)

A{n,m} Matches A at least n but not more than m times

(greedy)

Reluctant Closures

Closure Description

A*? Matches A 0 or more times (reluctant)

A+? Matches A 1 or more times (reluctant)

A?? Matches A 0 or 1 times (reluctant)

Logical Operators

Operator Description

AB Matches A followed by B

A|B Matches either A or B

(A) Used for sub-expression grouping

Backreferences
 Applications Manager 9.4.1

Backreference Description

\1 Backreference to 1st parenthesized sub-expression

\2 Backreference to 2nd parenthesized sub-expression

\3 Backreference to 3rd parenthesized sub-expression

\4 Backreference to 4th parenthesized sub-expression

\5 Backreference to 5th parenthesized sub-expression

\6 Backreference to 6th parenthesized sub-expression

\7 Backreference to 7th parenthesized sub-expression

\8 Backreference to 8th parenthesized sub-expression

\9 Backreference to 9th parenthesized sub-expression

Appendix B: awop_api.awrun - Requesting Tasks

Through Oracle
The preferred method of requesting tasks through Oracle is using the API awop_api.awrun package. This
procedure validates the requestor and password and supports the same functionality as the awrun command. Run
awop_api.awrun from the same Oracle user/schema as the Automation Engine (there will be errors if you attempt
to call it from another Oracle user).
The Oracle package procedure is shown below:

awop_api.awrun(tranmode IN VARCHAR2,results OUT NUMBER,error_text OUT

VARCHAR2,command IN VARCHAR2);

The command variable uses the same format as the command line awrun format. Examples of code from within
PL*SQL are shown below. The command variable uses the same format as the command line awrun format. For
details on the awrun command variables, see awrun - The Command Line API for Requesting Tasks.
Entering the Transaction Mode in API Calls
The transaction mode (tranmode) consists of two upper-case characters. The first character is the transaction type.
For the API awop_api.awrun package, the first character A is used to add. The second character controls the error
reporting method. For the API awop_api.awrun package, the second character F is the Oracle exception created
with error code and text. It will be fully rolled back.
Passing the Requestor and Password
The following code demonstrates passing the requestor and password with each request.

declare
results number;
error_text varchar2(80);
begin
awop_api.awrun('AF',results,error_text,'TEST_JOB -u SQLOPER -z s0pass -arg 5');
commit; end;
 Applications Manager 9.4.1

Appendix C: Task Action Order

Applications Manager will take the actions listed below in order they are listed for all tasks regardless of whether
they are Jobs, Process Flows, or Process Flow components. Some actions will not be relevant for every task. For
example, a stand-alone Job may have no predecessors. If an action is not relevant, the next action can be taken.
1. A task is inserted into the Backlog by being a:
• Scheduled Job or Process Flow.
• Scheduled and staged Job or Process Flow.
• Requested Job or Process Flow.
• Component in a Process Flow that is scheduled, staged and scheduled, or requested.
2. A task may be skipped if is:
• Inactivated in its Job, Process Flow, or Process Flow component definition.
• A component with a run or skip Calendar that prohibits it from running.
• A component with the current day of the week unchecked for eligibility.
3. The task waits until start time is not in future. Start times may be in the future when tasks are staged or when
requests are post-dated.
4. Applications Manager waits for the task's predecessor requirements to be met.
5. Applications Manager waits for the task's necessary Automation Engine, Agent, and Queue capacity to be
available.
6. Applications Manager evaluates and executes any BEFORE conditions.
7. The task is started.
8. Applications Manager evaluates and executes any DURING conditions.
9. The task finishes.
10. The task executes any Output Scans.
11. Applications Manager evaluates and executes any AFTER or DELETED conditions.
12. A record of the task's success or failure is written to History. Whether a task remains in the Backlog when it
fails is determined by the Stay in queue on abort setting in its Job definition.
13. The task executes Notification.

8 Administration Guide
The Administration Guide is a comprehensive procedures manual that covers all aspects of
Applications Manager administration.
The Administration Guide is a comprehensive procedures manual that covers all aspects of Applications Manager
administration. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.
 Applications Manager 9.4.1

About This Guide

The Administration Guide is a comprehensive procedures manual that covers all aspects of Applications Manager
administration. It is part of the complete Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Applications Manager Administration

If you are an Applications Manager administrator, you will be responsible for ensuring the system is up and running,
and that Users can access the system. How much more you are responsible for will depend on the structure of your
IT shop. At the very least, you will probably be expected to:
• Ensure that the Applications Manager Automation Engine, Agents, RMI server, and Web server are up and
running.
• Provide Applications Manager User IDs and Logins to developers, production analysts, operations personnel,
network administrators and database administrators.
• Set the Automation Engine options.
You may also be responsible for one or more of the following:
• Defining Host and Database Logins
• Defining Output Devices
• Managing retention of Applications Manager records and Report output
• Migrating Applications Manager objects between development, test, and production instances
Each of these responsibilities is described in this manual.

Configure SMTP Authentication

You can use the following procedure to configure SMTP authentication for the master agent.
1. In the Applications Manager, go to Object Admin > Administration > Agents.
2. Select the master agent.
3. Click Edit.
4. Click the Email tab.
5. Enter appropriate details in the following fields.

Field name Required Description

Host Yes The SMTP server location.

Port Yes The port that the SMTP server uses for SMTP communication.

Sender Yes The email ID that is configured on the SMTP server to identify the email
sender.
 Applications Manager 9.4.1

Authentication Select this checkbox to enable SMTP authentication .

Username The username of the SMTP server.

Password The password of the SMTP server.

Use SSL/TLS Select this checkbox to use SSL for communication.

SSL Certificate Click Browse to upload the SSL certificate.

6. Click Test.
7. Click Apply.
8. Click OK.

Viewing User Connection Information and Sending Broadcasts

From the View menu, you can open the Connections window to:
• View a Report of Users who are logged into this Applications Manager instance.
• Broadcast a message to Users who are logged into this Applications Manager instance.
• View a list of RMI connections to this Applications Manager instance.
This topic describes the features available from the Users tab. The next topic describes the features available from
the Servers tab.
Viewing User Connections and Reports
If you would like to know who is logged into Applications Manager, you can open the View menu and select View
connections. Applications Manager will display the Connections window with the Users tab selected as shown
below. For example, you might want to know who is logged into an Applications Manager Automation Engine if you
were going to stop the Applications Manager processes. Users who do not exit client session cleanly may remain
listed on the Users tab of up to 15 minutes.

The Connections window is limited to Users who have the DBA User Group. If you do not have access to it, see
your Applications Manager administrator.
Viewing the AW_CLIENT_LOGINS_REPORT
Additionally, the AW_CLIENT_LOGINS_REPORT Report object allows you to select a time period, list of Users,
and list of statuses to see who has (or is) logged into a client session. An example is shown below.
 Applications Manager 9.4.1

Broadcasting Messages
You can send a message to everyone who is logged into the Applications Manager instance. To send a message,
you enter the text in the box at the bottom of the Users tab as shown below and click the Broadcast button.

Applications Manager displays the message in a Broadcast Message window shown below for all Users who are
logged into the system.
 Applications Manager 9.4.1

Viewing Server and Agent Connection Information

The RmiServers tab in the Connections window displays connection information about the RMI servers and the
Applications Manager Agents. The image below shows a typical listing for an Automation Engine and its Local
Agent, one RMI server, and several Agents.

The Connections window is limited to Users who have the DBA User Group. If you do not have access to it, see
your Applications Manager administrator.
The Agent column identifies the type of component.
• The Automation Engine is indicated by a blank in the column.
• RMI servers are indicated by the entry "RmiServer".
• Agents have their name displayed.
RMI Server Information
 Applications Manager 9.4.1

In the image above, the Automation Engine is shown at the top of the table. Its session ID is 3025715. Its
corresponding RMI server (RmiServer) has the same session ID. The Automation Engine's Local Agent is named
V9AM01 and displays the same IP address as the Automation Engine's RMI server.
The last column in the table, Master, applies only to the RMI servers. If "Ok" is displayed in the column, it indicates
that the RMI server can support the Automation Engine. There are two scenarios where you might want more than
one RMI server supporting an Automation Engine:
• Failover. If the primary RMI server is unavailable, Applications Manager will automatically switch to the
secondary RMI server.
• Client load. If you have a large number of clients connecting to Applications Manager, you may wish to use a
second RMI server to handle the client transactions.
To activate an RMI server to serve the Automation Engine, double-click the entry in the table. This will toggle the
entry from "No" to "Ok". To toggle the entry back to "No", double-click it again.
Agent Information
The Agents are listed in the table for information purposes only. Each entry provides an Agent's IP address, port
number, session ID if active, and a date stamp for the last activity. This information can be useful if you are having
network communication problems. The Automation Engine column does not apply to Agents.

Viewing Assigned Objects

If you are curious about the objects that you have access to based on the User Groups you have been assigned,
you can select View Assigned Objects from the main View menu. Applications Manager will display the Assigned
objects window shown below.
 Applications Manager 9.4.1

The window shows the name of the object, its description, the type of object, the User Group the object is assigned
to, and other information.
This information is designed primarily as a troubleshooting tool. Note the Copy button at the bottom of the window.
You can use it to copy the information to the clipboard and paste it into an email message that you would send to
Broadcom Support.
Refreshing Assigned Objects
If you feel the information in the Assigned objects window may be out of date, you can select Refresh Assigned
Objects from the View menu. This updates the information displayed in the Assigned objects window and in all
selector windows.
In the selector windows, the Refresh button performs the same function as Refresh Assigned Objects.

Applications Manager Directory Structure

To understand Applications Manager operation, it is important to know the file structure of Applications Manager
and the location of particular files used for diagnosis.
 Applications Manager 9.4.1

The directories used most often during Applications Manager operation and troubleshooting are listed below. The
directories are located in the AW_HOME directory.

Directory Contains

bin Applications Manager shell scripts that call the

Applications Manager processes.

c Compiled, executable code for each of the Applications

Manager processes.

cddir Install files.

data Data files that store information used by Applications

Manager.

debug Flag files to selectively turn on DEBUG.

exec Predefined and custom Applications Manager shell

scripts.

export Files generated by the Applications Manager Export

utility.

import Files generated by the Applications Manager Export

utility that are ready to be imported into Applications
Manager.

install Install files.

log Files generated during Applications Manager operations

including .log, .err, and .debug files.

map Files that match objects being imported to objects that

exist on the target systems. The map files have a .dat
extension.

out Output files generated by tasks run in Applications

Manager. Includes the standard out log files and the
output files generated by the task.

pipe Pipe files used by the Applications Manager

background processes.

run The pr and pm files created by Applications Manager

during task execution.

rte Java Run Time Environment files.

site Files used to set Applications Manager background

manager and client Environment Variables.

sql Miscellaneous SQL scripts used for troubleshooting,

installation, reporting, testing, and training purposes.

status Files that indicate the status of the background

programs.

tmp Temporary files.

web Web access and configuration files.

UNIX Home Directory Files

 Applications Manager 9.4.1

There are some important files in the Applications Manager home directory on a UNIX system. They are described
below.

File Description

.netrc Common UNIX configuration file for ftp remote login.

This configuration file may be used for running the
FTPJob. However, using a .netrc file can be a security
issue. You can replace the .netrc file with Applications
Manager Logins for each FTP host. The Applications
Manager Logins contain the username and password
information in encrypted form.

.profile UNIX script that sets the Users environment, directory

path, and other settings.

AWFILES.Z Zipped files of the Applications Manager installation

software.

release notes Shows the new and updated changes in the current
Applications Manager version.

Defining Output Devices

Applications Manager Output Devices include printers, faxes, and email. An Output Device definition can represent
a single device or a group of devices. Access to an Output Device is granted by assigning User Groups to the
Output Device.
Single Output Devices and Distribution Lists
An Output Device definition can define a single device or a group of devices using a distribution list. In the image
below, ALL_LASER represents a distribution list. If a distribution list is assigned to a Job or Process Flow, output is
sent to each Output Device in the list.

For information on defining single devices, see Defining Single Output Devices.
For information on defining distribution lists, see Defining Distribution Lists.
 Applications Manager 9.4.1

Output Groups
Output Groups are used to define organizational classes of Output Devices. When you define an Output Device,
you assign the Output Device to one or more Output Groups. When you assign an Output Group to a Job, output
from the Job can be sent only to the devices included in the Output Group.
Output Interfaces Objects and Interface Scripts
In Applications Manager, an Output Interface object is the interface to an Output Device. Associated with the
Output Interface object is an interface script on each Agent. The interface script builds the correctly formatted
print command that actually sends the output to the Output Device. An Output Interface can define any device
that processes output such as a printer, fax, and email. An Output Interface can be assigned to one or more
Applications Manager Output Devices.
How a Task Prints to an Output Device
The diagram below shows how output is sent from an Applications Manager task to a printer. In the Job's definition,
its output function is set to PRINT, and PRINTER_A is specified as the Output Device. In the Output Device
definition for PRINTER_A, the LP Output Interface object is assigned. The LP Output Interface specifies the LLP
interface script. The LLP interface script sends the print command to Printer A.
Troubleshooting Output Device Problems
For a table of symptoms, causes and actions for troubleshooting Output Device problems, see Troubleshooting
Output Device Problems.

Defining Single Output Devices

To add a new Output Device, you must enter name a description, select an Output Interface (and output option if
defined), select an auto output option, and assign one or more Output Groups.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Output Devices. If you do not have access to them, see your
Applications Manager administrator.
If you want the Output Device definition to define multiple Output Devices, you can create a distribution list.
Instructions for creating a distribution list are described in Defining Distribution Lists.
Procedure
To add a new Output Device definition:
1. From the Output Devices Selector window, click New.
Applications Manager Displays the Select Type window shown below.
 Applications Manager 9.4.1

2. Select the Single Device option.

Applications Manager displays the Output Devices window.
3. Complete the fields using the information below.
• Name
Name for the Output Device.
• Description
Description for the Output Device.
• Output Interface
The Output Interface that executes the print command and passes User-defined parameters to the printer,
email, fax, etc. The Output Interface defines the names of the static options fields, as well as basic command
design. For information on defining Output Interfaces in Applications Manager, see Defining Output
Interfaces.
• Output Option
Allows you to select a specific variable, setting, address, or orientation. Determined by the output options
defined for the Output Interface. For information on defining output options, see Adding Output Options to
Output Interface Definitions.
• Static options
Label fields defined for the Output Interface. The fields are used to define parameters. In the image at the
beginning of this topic Dest, Form, and Queue options are defined as static options. For information on
defining static options, see Defining Output Interfaces.
• Command
This field is read-only. As you fill in the Output Device fields, it displays the actual command executed by the
Agent.
• Auto Output Options
• Active: The output is sent to the Output Device.
• Inactive: The output will not be sent to the Output Device. The output will, however, be sent to the log file
for viewing.
• Alternate Device: When you select an alternate device, it will be used instead of the device you are
defining. This feature is useful if you need to temporarily take an Output Device offline, maybe for
maintenance, and want to redirect output to another device.
• Unassigned groups/Assigned groups
Use the arrow keys to assign/unassign the Output Device to one or more Output Groups. An Output Device
must be assigned to at least one group. For information on defining Output Groups, see Defining Output
Groups.

Defining Distribution Lists

If you want an Output Device definition to represent multiple devices, you must create a distribution list. A
distribution list contains the names of other Output Device definitions.
 Applications Manager 9.4.1

For example, if a distribution list is selected for a Job, that Job's output will be printed to all Output Devices listed
in the distribution list, even if the Job's requestor does not normally have access to one or more of the Output
Devices.
If you create a distribution list for an Output Device definition, you cannot assign an Output Interface to the
definition. Instead, each Output Device added to the distribution list uses its own Output Interface definition. This
allows the distribution list to include a variety of different Output Devices. If a distribution list is selected in the
Submit window, the LOG, PRINT, or STORE output function is overridden by the contents of the distribution list,
since the distribution list may contain Output Devices with different output function settings.
Procedure
To create a distribution list:
1. From the Output Devices Selector window, click New.
Applications Manager displays the Select Type window shown below.

2. Select the Distribution List option.

 Applications Manager 9.4.1

Applications Manager displays the Output Devices window.

3. Enter a name and description for the distribution list.
4. Assign/Unassign the distribution list to one or more Output Groups, using the arrow keys. For information on
defining Output Groups, see Defining Output Groups.
Adding Output Devices to a Distribution List
To add an Output Device to a distribution list
1. Click the New button in the Output Devices window.
2. Complete the fields in the Output Device window using the information below.
• Output Device
The Output Device to be added. The drop-down list includes all Output Devices you have previously defined.
• Output Option
Allows you to select a specific variable, setting, address, or orientation defined for the Output Interface. For
information on defining output options, see Adding Output Options to Output Interface Definitions.
• User
Determines who can view the output, and will be displayed in the header of the printout.
• Output Function
Determines how output is handled. On the Output window, output with a status other than LOG must be
queried for before it can be viewed. All output can be viewed from the Explorer window.
• LOG: Output is available for viewing from the Explorer and Output windows with an 'N' status. Use this
option for end-users who want to see their output immediately online.
• PRINT: Output is printed. The output is available for viewing from the Explorer and the Output windows
with a 'P' status.
• STORE: Output is stored and can be viewed from the Explorer and the Output windows with a 'D' status.
Use this option for output that may be needed for historical reference or troubleshooting.
• Copies
Number of copies. Applies only to printers.
3. To save the settings and add the prompt to the Job or Process Flow, click OK.

Defining Output Groups

Output Groups are used to define organizational classes of Output Devices. Output Devices can include, but
are not limited to, printers, fax machines, and email. Output Groups are used in printer, Job, and Process Flow
definitions. When you assign an Output Group to a Job, output from the Job can be sent only to the devices
included in the Output Group.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Output Groups. If you do not have access to them, see your
Applications Manager administrator.
Output Groups are different from Output Device definitions. Output Groups are used to group similar Output
Devices together into useful sets-they are basically a classification mechanism. Single Output Device definitions
contain the specific Output Device attributes for a single Output Device. A distribution list is a special case printer
definition that contains the Output Device attributes for several Output Devices.
Applications Manager ships with the ANY and SYSOUT Output Groups already defined. Applications Manager
will use the ANY Output Group as a default if no other Output Group is defined. You will probably want to define
additional Output Groups based on security issues (for example: a payroll check printer), printer capabilities (for
example: line, dot matrix, laser), location (for example: first floor, accounting) or some other useful classification.
Procedure
To add a new Output Group:
1. From the Output Groups Selector window, click New.
Applications Manager opens the Output Groups window shown above.
2. Enter a name and description for the Output Group.
The name can be up to 25 characters long. The description can be up to 30 characters long.
No Output Devices will be displayed in the Output Devices list when you first create the Output Group.
3. To accept the information for the new Output Group, click OK.
Assigning Output Groups to an Output Device
You assign Output Groups to single Output Devices and distribution lists using the Output Devices window shown
below. When an Output Device has an Output Group assigned to it, it is included the Output Devices box for that
Output Group. There is one Output Device assigned to the Output Group in this example.
 Applications Manager 9.4.1

Defining Output Interfaces

In Applications Manager, an Output Interface is an interface between Applications Manager and an Output Device.
Associated with the Output Interface is an interface script on each Agent. The interface script builds the correctly
formatted print command that actually sends the output to the Output Device. An Output Interface can define any
device that processes output such as a printer, fax, and email. An Output Interface can be assigned to one or more
Output Devices.
 Applications Manager 9.4.1

Applications Manager comes with an lp Output Interface defined for the standard UNIX lp command and the
Windows print command. An LPP interface script supports the lp Output Interface. The script is located in the
exec directory. The Output Interface must pass the correct information to the interface script to enable it to run the
appropriate command. For more information on the lp Output Interface, see LP Print Output Interface.
Applications Manager User Groups control access to Output Interfaces. If you do not have access to them, see
your Applications Manager administrator.
Procedure
To add a new Output Interface:
1. Make sure that you can print from the command line with the settings you intend on defining for the Output
Interface.
2. From the Output Interfaces Selector window, click New.
Applications Manager opens the Output Interfaces window shown above.
3. Complete the fields using the information below.
• Name
Name for the Output Interface. We recommend using the name of the printing command, for example lp for
the lp UNIX command.
• Command
The command that will be sent as the first element in the interface command. Each Output Interface
command calls a shell script in the exec directory of each Agent you run/print tasks from.
 Applications Manager 9.4.1

If the shell script does not exist on any or all of the Agents, you must create it. The LPP shell script for the
default lp Output Interface is shown below.

file=$1
shift
eval "lp $* $file"

This shell script takes the information passed to it by Applications Manager and builds an lp command with
the correct syntax (in this case, it reads the file name as the first argument and moves it to the end of the
UNIX lp command).
Be sure to make your scripts executable.
• Title
Passes a variable to the shell script for the Output Interface; often used to add a title to the banner page of
the printout. In the image above, Applications Manager substitutes the Applications Manager requestor name
for the variable " '%USR%' ".
• Space character
The character you would like to use as a placeholder for the space character. Instead of using the spacebar
on your computer, type the character in this field. The default is the '#' character.
• Copies
Specifies the number of copies to print when you submit a Job with the Submit window. Enter the
appropriate prep value character sequence in the Copies field. For UNIX lp, this is '-n'. If you do not enter a
flag in this field, any number entered into the Copies field in the Submit window is ignored.
• Static Options
Fields 1-3 are used to define parameters for a Job. These static option labels are displayed on the Output
Devices window. In the image above, the Dest, Form, and Queue options are entered.
The fields to the right of the 1-3 fields allow you to specify the format of each static option. If you leave these
fields blank, they will not populate their respective fields on the Output Devices window and Applications
Manager will not insert their flag value in the command.
• Output option
Allows you to request a specific variable, setting, address, or orientation. Determined by the output options
defined for the Output Interface. For information on defining output options, see Adding Output Options to
Output Interface Definitions.
• Command line
This field is read-only. As you fill in the fields, it displays the actual line executed by the Agent.
Using Environment Variables and Replacement Values
You can use Environment Variables and Applications Manager Replacement Values in Output Interface and printer
definitions. For example, the %USR% Environment Variable is used in the Title field for many Output Interfaces.
Applications Manager Replacement Values, such as {REQUESTOR} might be used in a To field defined for an
email Output Interface.
The list below shows the Applications Manager replacement variables and environment values that can be used in
Output Interface and Output Device definitions:

'{REQUESTOR}' - requestor
'%USR%' - requestor
'{SO_USER_NAME}' - requestor
'{SO_PRINTER}' - printer
'{SO_OUT_FUNCTION}' - out_function
'{SO_COPIES}' - copies
'{SO_MODULE}' - job
'{SO_OPERATOR}' - operator
 Applications Manager 9.4.1

'{SO_APPLICATION}' - application
'{SO_CHAIN_NAME}' - chain_name
'{SO_SEQ_NO}' - seq_no
'{SO_RPF_OPTIONS}' - rpf_options
'{SO_JOBID}' - jobid
'{SO_REF1}' - ref1
'{USR}' - requestor
'{REQUESTOR}' - requestor
'%usr%' - requestor
'{so_user_name}' - requestor
'{so_printer}' - printer
'{so_out_function}' - out_function
'{so_copies}' - copies
'{so_module}' - job
'{so_operator}' - operator
'{so_application}' - application
'{so_chain_name}' - chain_name
'{so_seq_no}' - seq_no
'{so_rpf_options}' - rpf_options
'{so_jobid}' - jobid
'{so_ref1}' - ref1
'{usr}' - requestor
'{requestor}' - requestor

An alternate way of passing a variable to the title for the Output Interface is to edit the interface script to something
like the following:

file=$1
shift
eval "lp $* -t 'a $jobid b $module' $file"
exit $?

The option -t allows you to use any Environment Variable. The down side to this is that it will only work during the
print from a task run. Then environment will be set up for the Replacement Values such as run_id and chain_id. If
you do a print from the File Viewer, those Replacement Values do not have a value.

Adding Output Options to Output Interface Definitions

Output options allow Users to request a specific variable, setting, address, or orientation during run-time. They are
defined on the Output Interfaces window.
In Applications Manager, an Output Interface object is an interface between Applications Manager and an Output
Device. Applications Manager allows for static and output options to be defined for Output Interfaces. They are set
by the User at the time they select the Output Device.
You define Output Device options on the Output Interfaces window. Using this option, Users can select a value
from a predefined list or enter a value when defining/requesting Jobs and Process Flows, or when adding a User.
This feature is handy when creating a single Output Device definition that you want to use with multiple settings
(for example: portrait and landscape printer settings, or email addresses). The output option, if used, is always the
second argument passed on the Output Interface command line (after <file>). The image below illustrates the four
versions of the output option available in the Selection type field.
 Applications Manager 9.4.1

The Output option fields are described below.

• Selection type
• None: Variable output options will not be used.
• Fill-in: Users enter their own value.
Be sure you design your Output Interface command script to anticipate the use (or omission) of the variable
output option.
• List: Users can select a value from a list of choices.
• Fill-in/List: Users can select from a list of choices or enter their own value.
• Option
Insert individual values into this field. Click Add to add the value to the option list.
• Option list
 Applications Manager 9.4.1

Shows listing of values entered.

In the Output Devices window shown below, Applications Manager builds the Output Interface command as you fill
in the static and variable options with values. As you make a change, Applications Manager reflects that change in
the Command field. This example shows an e-mail print device.

The Output Option field only appears in other Applications Manager windows if an output option has been defined
for the Output Interface assigned to the Output Device.

LP Print Output Interface

Applications Manager ships with an lp Output Interface that uses the LPP interface script to handle basic UNIX
printing and the LPP.BAT interface script to handle Windows printing. The code from the LPP and LPP.BAT scripts
is shown below.
LPP script:

file=$1
 Applications Manager 9.4.1

shift
eval "lp $* $file"
exit $?

LPP.BAT script:

@echo off
set file=%1
shift
print %1 %2 %3 %4 %5 %6 %file%

The scripts take arguments passed by the Applications Manager Output Interface object and build the appropriate
print command. The first argument passed is the file to be printed, so the scripts move the file name to the end of
the command line so it conforms to the syntax of the lp and lpp commands.
Arguments Determined by Output Device Definition
The arguments sent to the LPP interface script originate from the Output Device definition in Applications Manager.
The image below shows the definition for an Output Device called TEST.
 Applications Manager 9.4.1

In the example above, the lp Output Interface is assigned to the Output Device. The Output Interface (as shown
below) defines the optional fields Dest, Form, and Queue, as well as basic command design.
The Output Interface Command line field shows that the LPP interface script runs using the following arguments:
• <file>: the output file
<copies>: number of copies
<%USR%>: the requestor name
 Applications Manager 9.4.1

The first argument in the command line is always the file name. The command line can include four additional
arguments (in addition to the number of copies and a title string). You can specify the format for the arguments in
the Output Interface command.
The first of the four possible arguments is known as the output option. It's specified in the Output Option group
box You can create a drop down, fill-in list box or free text field. In the image below, the values 'Landscape' and
'Portrait' are part of a drop down list with the value 'Portrait' set as the default value. The output option argument is
represented in the command line by the <option text> entry.
 Applications Manager 9.4.1

The output option allows users to dynamically modify one of the Output Interface arguments. This feature can
eliminate the need to create two Output Device definitions for each printer in your network, for example one
portrait and one landscape. Instead, you can create a single Output Interface with a portrait/landscape option. An
Applications Manager User can select the appropriate option when they select the Output Device.
Notice that the three arguments shown in the Static options group box in the image above are named Dest,
Form, and Queue, and that the flags for each appear in the Output Interface Command line shown at the bottom of
the window.
Specifying the Arguments for the lp Output Interface
The (partial) syntax for the UNIX lp command is as follows:

lp -d dest -f form_name -q queue -n copies -t title

The prep values used by each argument and value are listed below.
 Applications Manager 9.4.1

This argument and value: Uses this prep value:

-d <dest> #-d#

-f <form-name> #-f#

-q <queue> #-q#

-n <copies> #-n#

-t <title> #-t#

To minimize the work that has to be done by the LPP interface script, the arguments specified in the Output
Interface definition should closely match the syntax of the lp command.
Notice that each argument in the Output Interface requires a flag in its Format field, (in Windows, referred to as a
switch). After each flag is an optional string or value appropriate to the argument. Include spaces by inserting the
designated Space character field (# in these examples). For the lp command, each flag begins and ends with a
space.

Emailing Output
Applications Manager ships with an email Output Interface object and an Output Device both named AW_EMAIL.
You can use the AW_EMAIL Output Device to send email on any supported operating system.
Setting Up the AW_EMAIL Output Interface
In the AW_EMAIL Output Interface object definition (as shown below), add any email addresses you want Users
to be able to select as output options to the Option List. You can add individual email addresses using the Add
button, or select email addresses specified in for Applications Manager Users with the Select button.
 Applications Manager 9.4.1

Do not copy the AW_EMAIL Output Interface. It will only work when named AW_EMAIL.
Setting Up the AW_EMAIL Output Device
In the AW_EMAIL Output Device object definition, optionally select values for the following fields:
• Output Option
A default email address.
• Subject
The subject for the email.
• From
A required valid email address that emails will say they are from. You can enter a static value or you can use the
Replacement Value {email} to pick up the Users as requestors email address.
• Attach, ZIP, PDF, In Body
Pick an option to either send the output file as an attachment, include it in an attached zip file, attach it as a PDF
file, or include it in the message body.
 Applications Manager 9.4.1

A sample AW_EMAIL Output Device object is shown below.

Remember, for a task to send output to any Output Device including an email address, its output function must be
set to PRINT.
If there is an error printing to the AW_EMAIL Output Device, Applications Manager will write error messages to the
task's comment (not its task log file).
Specifying Email Body Text with the AW_EMAIL Message Template
When output files are attached to an email, the task's run_id Replacement Value will be entered as the email body.
To use custom text as the email body, create a Message Template named AW_EMAIL. You don't need to assign
the AW_EMAIL Message Template to the Job. Message Templates can include Replacement Values and Subvars.
A sample Message Template is shown below.
 Applications Manager 9.4.1

For more information on Message Templates, see the Development Guide.

Emailing Output to Multiple Addresses
To send output to more than one address, create an Output Device for each email address and add them to a
distribution list. For information, see Defining Distribution Lists.
Emailing Output without Defining an Email Output Device
Another method for sending output to one or more email addresses is by defining Applications Manager
Notifications and assigning them to Applications, Program Types, and Jobs. For more information, see the
Development Guide.

Faxing Output
You can create a fax Output Interface that has arguments for file name, fax number, sender, and recipient.
In addition to printing and email, you can also send output to a fax. To send output to a fax, a fax modem must be
set up as a UNIX device and be accessible from the command line.
The command for faxing output might be sendfax with the following syntax:

sendfax <fax phone number> <output file> <sender> <recipient> <organization>

Output Interface Definition

The Output Interface definition for the fax might look like the following.
 Applications Manager 9.4.1

KIKI: The Title field is used to capture the name of the requestor and add it to the fax as the sender.
Output Interface Script
The Output Interface script for the fax Output Interface might look like the following:

file=$1
number=$2
recipient=$3
organization=$4
sender=$5
eval "sendfax $number $file $sender $recipient $organization"

Output Device Definition

 Applications Manager 9.4.1

An example fax Output Device definition is shown below. The fax will go to the Technical Support group at ABC
Company.

Troubleshooting Output Device Problems

If you are having trouble printing output from Applications Manager, use the following table as a troubleshooting
guide.
 Applications Manager 9.4.1

Symptoms Causes Action

Printing to most Output Devices is The Inactive radio button is selected Make sure the Active radio button is
successful. However, one or more in the Output Device's Auto Output selected in the Output Device's Auto
devices do not print, and don't give Options box. Output Options box.
any error messages.
The interface script assigned to the 1. Verify that the interface script
Output Device's Output Interface is has execute permissions for
not defined correctly. Applications Manager.
2. After the interface script to
echo its command line to a log
file rather than executing the
command.
For example changeeval "lp
$* $file" toecho "lp $* $file" >
$AW_HOME/exec/LPP.log.
3. Look at the log file (for example,
LPP.log) to check that the syntax
of the command is correct.
4. Execute the log file to see if it
prints the document.
If it prints, then the problem may
be with Applications Manager.
Call Broadcom Support.
If the file does not print, then the
problem is with your system.

An Applications Manager error Any Record the details of the message,

message states that printing was then call Broadcom Support.
unsuccessful.

Output files are not being created. Permissions on the output directory Verify that Applications Manager
may not be set correctly. has write permission in the output
directory.

New files cannot be written to the Verify that Applications Manager can
output directory because: write a file to the output directory.
Free some disk space or clean out
• There is no free disk space
unneeded files as necessary.
• There are too many files already
in the directory.

The task failed before it could Check the Backlog or History to see
generate any output. if the task aborted. Determine why
the task aborted.

Output files can be viewed from the The output was generated with an To view the output, query the Output
Explorer window, but they do not output function of PRINT or STORE. window for status codes of PRINT
appear on the Output window. and/or STORE.
To make the output files viewable
by default on the Output window,
set the output function for the Job to
LOG.

The SYSOUT Output Device was Select a different Output Device.

assigned to the Job or Process Flow.

Debugging Printer Problems

When troubleshooting printing issues, it's probably best to start by debugging the task's system output file (the o
file) in addition to screen shots of the printer and the spooler from the Applications Manager client. Make sure the
 Applications Manager 9.4.1

Output Interface's (spooler's) print command works from the command line. Check the configuration settings before
getting debug.
To turn on printing debug, create the following 0-byte files in the debug directory (notice that here AWMAIL and
SYS_PRINT are listed to cover both AWMAIL printing problems and system printing problems):
• PRINTEM
• PRINTEM2
• AWMAIL
• SYS_PRINT
Then run the task and look for a awprint*log file in the log directory.

Applications Manager Security

Using the Applications Manager security features, you can control access to Applications Manager, objects within
Applications Manager, and to databases and hosts accessed by Jobs.
Security is always a major concern with client/server programs. Applications Manager lets you control security on
three levels:
• Access to Applications Manager is controlled with User objects.
• Access to Applications Manager functions is controlled with User Groups.
• Access to databases and hosts is controlled with Logins.
Using the three security levels, you can fine tune Applications Manager to give different groups access to only the
areas of Applications Manager they need. The different access controls are illustrated below.

Defining Users
When you add a User to Applications Manager, you define the User's name, password, Login group, maintenance
User Group, and default output directory. You can assign Applications Manager Users specific options such as
View Other Users' Output for the Output window. For more information on Users, see Defining Users.
Defining User Groups
You control access to Applications Manager windows and objects using User Groups. Think of User Groups as
containers to which you add objects and Users. Users have access to all objects with which they share a container.
Users and other Applications Manager objects can be placed in more than one container. You can further restrict
access by designating Edit authorization to some User Groups and not to others. The number of objects and Users
you can assign to a User Group is unlimited. Objects and Users can be assigned to more than one User Group.
Users have access to all the objects in all the User Groups to which they are assigned. For more information on
User Groups, see Defining User Groups.
Defining Logins
Use an Applications Manager Login to give Users access to a database, application, or host without their having
to know a password. The Login object includes a name, password, Login type, and other Login-specific options.
Login passwords are encrypted using AES (Advanced Encryption Standard also known as Rijndael, which is a
block cipher adopted as an encryption standard by the US government) instead of a proprietary algorithm. After
you create a Login, other Users can assign the Login to Jobs and Process Flow components. For information
on defining Database Logins, see Defining Database Logins. For information on defining Host Logins, see the
 Applications Manager 9.4.1

Development Guide. For information on specific Application Login types, see your related Applications Manager
interface or extension documentation.

Defining Users
User objects control access to Applications Manager. They:
• Allow users to log into the Applications Manager client.
• Specify settings and User Options while the User is logged into an Applications Manager client session.
• Specify settings and User Options when the User is specified as the requestor for an ad hoc request or in a
schedule.
To edit or delete existing Users, you must have the Select Requestors User Option and the necessary User Group
access. If you do not have access to them, see your Applications Manager administrator.
Procedure
To add a new User:
1. From the Users Selector window, click New.
Applications Manager opens the Users window shown below.

2. Complete the fields using the information below.

• User
The name the user will enter on the Applications ManagerLogin window. Entry can be 30 characters long.
• First Name/Last Name/Description
The user's first and last name or description.
 Applications Manager 9.4.1

Warning: While special characters are allowed in these fields, they can cause Jobs to go into
a Launch Error status, unless the values are surrounded by quotes. The syntax for the quote
characters differs depending on your operating system. Therefore, using special characters in these
fields is done at your own risk.
• Active
Designates the User as active or inactive. An inactive User cannot log in to Applications Manager. However,
scheduled tasks can run with an inactive User in their Requestor field.
• LDAP Authorization
Applications Manager passes the User to an LDAP server for authentication when this User logs into
Applications Manager. With LDAP authorization, the User's password is stored on the LDAP server instead
of in the Applications Manager database (the Password field on this window is still required when this box
is checked, even though it is not used). If the LDAP server successfully verifies the User name, it returns an
authentication allowing the User to log into Applications Manager.
To use LDAP authorization for an Applications Manager User:
• A User must exist on the LDAP server with the same name as this Applications Manager User.
• The LDAP settings must be correctly specified for the Automation Engine.
For more information on LDAP settings for the Automation Engine, see Setting Automation Engine Options.
• Password
The case sensitive password for the User. Entry can be 30 characters long. To increase User security you
can add User audits. User audits enforce rules for selecting User passwords. For more information, see
Adding User Password Audits.
• Expire interval
The number of days until the User's password will expire (forcing them to specify a new one). You can set the
expire interval to 0 and the Login password will not expire in the future.
• Last modified
This non-edit field displays the date and time the password was last changed.
• Awexe range
Correlates to a range of options listed in the awserver_sql.dat file located in the data directory. Users will
have access to the functions assigned to them from the command line. Ranges are listed below:
• 1000-1999: Used for Applications Manager background processes.
• 2000-2999: Utilities for the general User.
• 3000-4999: Reserved for consulting.
• 5000-9999: Used for custom definitions.
If you enter 2000-2099, the User will have access to all the Applications Manager command line interface
functions. However to change any data, they will be required to supply an Applications Manager user name
and password. For more information on the command line interface, see the Development Guide.
The awexe range can be a comma separated list of multiple ranges.
For example: 1000-1999,3000-3999
Users assigned to a Remote Agent require an awexe range of 1000-9999 for the Agent to start. For more
information on assigning a User to an Agent, see Defining Remote Agents.
• Login
Applications Manager uses this field to specify the database or host Login for the User. This Login is only
used when Jobs have User's Login selected on their Job's Execution Options tab.
• Maintenance User Group
This option lets you specify a User Group that will automatically be assigned to all objects created by the
User. To select a User Group from the drop-down list, it must be assigned to the User. For more information,
see Assigning Objects to a User Group.
With the objects and the User assigned to the same User Group, the User can edit the objects he creates.
If you do not assign a maintenance User Group to a User, and the User creates an object such as a Job or
Process Flow, he will not be able to edit the object after he creates it.
 Applications Manager 9.4.1

When an object is assigned to a User's maintenance User Group, that User cannot remove the object from
that User Group. If you need to remove an object from a User's maintenance User Group, you must be
logged in as a different User.
Whenever a User creates a new object, the object is automatically assigned to the DBA User Group even if
the User does not have DBA authority. This ensures that the Applications Manager administrator can get to
the object to edit or delete it.
• Output Device
This Output Device will be used for ad hoc requests under this User's name. The Output Device must be
included in an Output Group assigned to the Job or Process Flow. This setting has no effect on scheduled
tasks.
• Output Option
Sets a specific variable, setting, address, or orientation for the Output Device. This field appears only when
an auto output option has been defined for the selected Output Device.
• Output Directory
Applications Manager normally sends output to the directory specified for the Agent. Entering a directory in
this field overrides the Agent directory and the Job directory. This field may be up to 32 characters long. If
you enter a directory here, be sure it exists and that Applications Manager has read/write permissions to it.
You can use Substitution Variables in this field.
If an output directory is specified for both the Job and the User, the output directory of the User will override
the Job setting.
• Email
The User's email address. This value can be retrieved for a User as a requestor using the {email}
Replacement Value.
• Fax
The User's fax number. This value can be resolved for a User as a requesto using the {fax_no} Replacement
Value.
• Phone
The User's telephone number. This value can be retrieved for a User as a requesto using the {phone_no}
Replacement Value.
• Text Message Email
The User's text message email address. This value can be retrieved for a User as a requesto using the
{text_msg} Replacement Value.
Automation Engine Options That Affect Applications Manager Users
The settings for the following Automation Engine options affect all Applications Manager Users:
• Disable user after 3 consecutive failed login attempts: Unchecks the Active box for a User if they enter the
wrong password three consecutive times when logging into the Applications Manager client.
• Force password change on new users: Forces Users to change their password the first time they log into
Applications Manager.
• Force password to contain both alpha and numeric characters: Forces Users to include both alpha and
numeric characters in their User password.
• Require password length of 6 characters: Forces Users to include at least six characters in their password.
For information on setting Automation Engine options, see Setting Automation Engine Options.

Setting User Options

The Applications Manager User Options control User access to specific features. By default, no User Options are
assigned to a new User.
 Applications Manager 9.4.1

When you initially install Applications Manager, the script automatically creates the following Applications Manager
Users.
• SQLOPER (the default User), Applications Manager automatically assigns several User Options to this Login.
• A User named after the Login you are using to install Applications Manager. This User will have no default User
Options.
Assigning Options to a User
To assign options to a User:
1. From the Options tab of the Users window, select the values you want to use.
• Select Requestors
Allows the User to:
• Select all currently defined Users from the Requestor list box on the on the Requests window.
• Select all currently defined Users from the Requestor list box on the Schedule tab for Jobs and Process
Flows.
• Edit and delete User definitions (if the User has the necessary User Group access).
• Query for Users as requestors for History Queries. To query for requestors, you must have the Users you
are querying for in a User Group with Edit authority.
• Edit Other Users' Tasks
Allows the User to:
• Take actions (KILL, DELETE, etc.) on tasks in the Backlog run by other Users. To take an action on a
task, Users also need the task's Job/Process Flow definition in one of their User Groups (with or without
Edit authorization).
• Edit tasks in the Backlog run by other Users. To edit all the details for tasks in the Backlog, Users also
need access to the objects assigned to the Job/Process Flow.
• View all tasks in History, regardless of who submitted them.
• Create Procedure SubVars
Allows the User to use database procedures when defining Substitution Variables.
• FTP Output Files
 Applications Manager 9.4.1

When assigned, the User will have access to the File Transfer option when printing from the File Viewer
window.
• Hide Files on the Output Window
When assigned, the User will have access to the Hide button on the Output window.
• Show Read-Only Prompts
When assigned, the User will be shown read-only prompts on the Submit and Task Details windows.
Without this option, prompts without Allow Changes set will be read-only.
• Take Actions on Agents
Allows the User to start, stop, idle, resume, or reset the Automation Engine or any Agent from the Explorer
window. The User does not need User Group access to the Agents.
• Set Task Name Suffixes
Allows the User to add a suffix to Job/Process Flow names when requesting them. This will prevent the
requests from satisfying any predecessors since the name is changed.
• Receive RmiServer Error Broadcasts
When this User is logged into Applications Manager, any RMI errors will be displayed in a pop-up window as
they occur. Additionally, if any RMI errors occurred since the last time the RMI server was started, the last ten
errors will be displayed in a pop-up window each time the User logs on.
If you have the DBA User Group, you can clear the RMI errors without stopping the RMI server by selecting
Clear RMI Errors from the View menu on the Applications Manager Desktop.
• Select Queues For Requests
The User can select a different Queue when submitting tasks on an ad hoc basis.
• View SYSOUT Device Output Files
Displays output that is assigned to the SYSOUT Output Device on the Output window if the User does not
have the View Other Users' Output User Option described below.
• View Other Users' Tasks
Allows the User to view all tasks in the Backlog and History, but not edit them.
• View Other Users' Output
Output from all Users will be listed in the Output window for this User.
2. To accept the values, click OK.
Assigning Users to User Options
In additions to being part of User objects, User Options are a special object type that you can add to User Groups
like any other object to give all Users in the User Group those User Options. You cannot add, edit, or delete User
Option objects like other Applications Manager objects.

Customizing Applications Manager Defaults with DEFAULT_USER

The Applications Manager administrator can customize defaults for the Applications Manager interface by creating
an Applications Manager User named DEFAULT_USER. The Applications Manager administrator can:
• Select the default language assigned to Users.
• Control the default information displayed in tables within many of the Applications Manager screens including
the Backlog and History.
• Control the default task, Agent, and Automation Engine status colors.
Each of these settings can be overridden at the User level.
Creating the DEFAULT_USER
To create the DEFAULT_USER shown below, create a new User by following the information provided in Defining
Users.
 Applications Manager 9.4.1

The language you select from the Language drop-down list determines the default language for all Users that
have 'Default' selected in this field. The User can override the default language when logging into the Applications
Manager client. In the image above, the default language is English.
Setting Custom Defaults
Once you create the DEFAULT _USER, you can log into Applications Manager as DEFAULT_USER and customize
table displays and status colors as explained in the User Guide. Each setting specified for the DEFAULT _USER is
applied to any User who does not select a different option for that setting.
For example, if you select the color pink to represent tasks in an INACTIVE status, but a User selects the color
blue, INACTIVE tasks would be displayed in blue for that User, but they would be pink for all Users who have not
selected a color.
Setting Default Date/Time Formats
In the Explorer window, Applications Manager displays task start and end times, as well as virtual workday and
database times, and refresh time. As the Applications Manager administrator, you can control the format of these
times by editing the Options.properties file.
The location for the Options.properties file is:
UNIX:

$AW_HOME/web/classes
 Applications Manager 9.4.1

Windows:

%AW_HOME%\web\classes

The section of the file you edit is shown below in bold text:

# Date formats
#
# j: Java / db: Database
# Macro: larger time segments / Micro: small time segments
# Ex: Java 'MM-dd-yyyy' == Oracle 'mm-dd-yyyy'
jDateFormatMacro=MM-dd-yyyy

jDateFormatMicro=HH:mm:ss z

Applications Manager will display the time zone when a z is included in the jDateFormatMicro line as shown
above.

Adding User Password Audits

To increase User security, you can add User audits. User audits enforce rules for selecting User passwords.
There are several predefined password rules you can select from the Automation Engine Options tab of the
Automation Engine/local Agent including the following:
• Disable User after 3 consecutive failed login attempts
• Force password change on new Users
• Force password to contain both alpha and numeric characters
• Require password length of 6 characters
• Disable clearing of Login passwords on re-login
If you wish to increase User security beyond these rules or want to implement rules like these, you can add
additional password rules with User password audits. For example, you may wish to create an audit that requires
a User's password to be at least eight characters long. If the user clicks Apply or OK, and their password is less
than eight characters, a pop-up dialog will be displayed with the message, "Password must be greater then 8
characters".
To add custom password checks, you'll need to replace the custom_password_audit procedure that is called by
the so_user_table_trig trigger on the so_user_table. Here is the code from the trigger that calls the procedure:

custom_password_audit
(:new.so_user_name,:new.so_db_passwd,:new.so_passwd_chg);

You can add audits to the User passwords using the custom_password_audits.sql file in the sql directory.
The custom_password_audits.sql script that comes by default in the sql directory does not perform any audit
functions. To implement audit functions do the following:
• Copy the unwrapped custom_password_audits.example file in the sql directory to
custom_password_audits.sql.
• Modify the custom_password_audits.sql file as desired.
• Log into SQL*Plus as the Applications Manager Oracle user and execute the custom_password_audits.sql
script.
Since custom_password_audits.sql is a user-customizable script, it will not get overwritten on upgrades. You will
get a new custom_password_audits.example file when upgrading, but not a custom_password_audits.sql file.
 Applications Manager 9.4.1

Modifying the custom_password_audits.sql File

The custom_password_audits.example gives an example of how to implement User password audits. When you
copy the custom_password_audits.example file in the sql directory to custom_password_audits.sql, it includes
the following four audits:
• Passwords must be least eight characters long.
• Passwords must contain at least one letter and one number.
• Passwords must not contain values entered in the User, First Name, or Last Name/Description fields.
• Passwords must not be reset for seven days after the previous reset.
An example of what you might run is shipped with the product in the customer_password_audits.example
file located in the sql directory. You may need to add, edit, or remove these audits to meet your needs. The
customer_password_audits.example is shown below:

create or replace procedure custom_password_audit

(so_user_name in varchar2,so_db_passwd IN varchar2, so_passwd_chg date) is
begin
-- scripts exits without taking any actions as shipped
goto no_edits;

-- at least 8 characters in length

IF length(so_db_passwd) < 8
THEN raise_application_error (-20081,
' Password must be greater then 8 characters');
END IF;
-- must contain at least one letter and one number
IF so_db_passwd = translate(so_db_passwd,'0123456789','')
or length(rtrim(translate(so_db_passwd,'0123456789',''))) = 0
THEN raise_application_error(-20081,so_user_name||
' Password must contain at least one letter and one number');
END IF;
-- must not contain user name
IF upper(so_db_passwd) like '%'||upper(so_user_name)||'%'
THEN raise_application_error(-20081,so_user_name||
' Password must not contain the user name');
END IF;
-- must not allow reset for 7 days after reset, etc
IF so_passwd_chg +7 > sysdate
THEN raise_application_error(-20081,so_user_name||
' Password cannot be changed for at least 7 days from last change');
END IF;

<<no_edits>>
null;
END;
/

Note that this example doesn't actually do any checks because of the goto no_edits; line shown is bold above. To
do anything, that line would have to be removed or commented out.
 Applications Manager 9.4.1

After replacing the procedure, either run awinstall and choose the recreate triggers install option (this can be done
with the back end running), or recompile the trigger manually with this:

alter trigger so_user_table_trig compile;

Inactivating Custom Password Audits

If you decide you want to inactivate the custom password audits, you must run the custom_password_audits.sql
script without any rules specified as shown below.

create or replace procedure custom_password_audit

(so_user_name in varchar2,so_db_passwd IN varchar2, so_passwd_chg date) is
begin
null;
END;
/

Adding Applications Manager Users with the so_add_user Procedure

If you can quickly add multiple Users to Applications Manager using the so_add_user procedure from SQL*Plus.
The Users you create this way will have no User Options assigned to them.
Use the following procedure to add Users from SQL*Plus:
• From the Automation Engine's sql directory, log into SQL*Plus as the Applications Manager Oracle User.
• Issue the following:

SQL> set serveroutput on

• Execute so_add_user for each Applications Manager User you wish to add. Be sure to commit afterward.

SQL> execute so_add_user (<User name>,<active flag>,<login source>,<first name> ,<last

name>,<db passwd>,<pswd max intvnumber>,<User Group name>,<maint User Group>, <spl out
path>,<db Login>)

Example of command line:

SQL> execute so_add_user ('DOE','Y','P','John','DOE','s0pass',0,'DBA','','','')

PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.

These Users will have no User Options assigned to them. To create multiple similar Users with the same User
Options, create one User and use the Copy feature for the others.

Working with User Groups

You control access to Applications Manager windows and objects using User Groups. Think of User Groups as
containers to which you add objects and Users. Users have access to all objects with which they share a container.
 Applications Manager 9.4.1

Users and other Applications Manager objects can be placed in more than one container. You can further restrict
access by designating Edit authorization to some User Groups and not to others.
Organizing User Groups
User Groups give you unlimited flexibility in assigning access to Applications Manager objects. However, you may
want to start with some standard User Groups until you have worked with Applications Manager and have had time
to think through a more elaborate set of User Groups. The top row in the image below illustrates three typical User
Groups: programmer, operator, and end-user.

The image above also shows two additional programmer User Groups: edit and non-edit. The two User Groups
make it possible to give programmers read-only access to some objects, and edit access to other objects.
The programmers would be assigned to both User Groups. For example, you might give programmers read-only
access to:
• Objects that ship with the product (for example: system Jobs and Process Flows).
• Objects that might be created by an Applications Manager administrator (for example: Output Devices).
• Objects that might be created by a database administrator (for example: Logins).
• Certain objects such as Queues (to give access to the Explorer window).
On the other hand, you would give programmers edit access to the Jobs and Process Flows they create.
By having two User Groups, you have the flexibility to give a group of Users the access they require to accomplish
their Job. You would most likely want an edit and non-edit User Group for operators as well. End-users may only
require a single non-edit User Group because they would not be creating objects.
If you assign an object to an edit User Group and a non-edit User Group, the edit User Group will take precedence
and the User will be able to edit the object.
User Group Access not Inherited
User Group access is not inherited when you assign one User Group to another User Group. That means if you
assign USER_GROUP_A to USER_GROUP_B, and assign a User to USER_GROUP_B, the User will not have
access to the object in USER_GROUP_A.

Defining User Groups

After planning the User Groups you want to create, you are ready to define the User Groups. You can create as
many User Groups as you need. User Groups can incorporate any combination of objects, including other User
Groups. The User Groups window is shown below.

Procedure
To add a User Group:
1. From the User Groups Selector window, click New.
Applications Manager opens the User Groups window.
 Applications Manager 9.4.1

2. Complete the fields using the information below.

• Name
Name of the User Group
• Description
Description of the User Group
• Edit
Signifies this User Group as an 'edit User Group'. Users assigned to an edit User Group can do the following
things:
• Edit and delete all objects assigned in the edit User Group.
• Add objects if the corresponding User Authorities for the objects are assigned to this User Group or
another edit User Group that is also assigned to the User.
• Take actions on tasks in the Backlog, if the Explorer User Authority is assigned to this User Group.
For more information on User Authorities, see Understanding User Authorities.
Next Step
After defining a User Group, the next step is to add objects to it. For more information, see Assigning Objects to a
User Group.

Assigning Objects to a User Group

After creating a User Group, you assign objects to it by clicking the Assign tab. You can assign any type and
number of objects to a User Group. However, it is usually a good idea to organize User Groups so each control
access to a group of similar objects. For example, you might want to create one User Group to control access to a
set of Jobs, a second User Group to control access to a set of Output Devices, and a third User Group to control
access to a set of User Authorities.

Procedure
 Applications Manager 9.4.1

To assign objects to a User Group:

1. From the User Groups window, select the Assign tab as shown above.
2. Select an object type from the Object types list.
Selecting 'All' will display all User Groups.
User Authorities control user access to the Applications Manager windows. For more information, see
Understanding User Authorities.
3. Select the objects you want to include in the User Group.
Setting the Job/Process Flow Option
The Both, Request, and Output radio buttons on the bottom of the screen are only used when assigning Jobs and
Process Flows to a User Group. When you add those objects to a User Group, you can choose one of the options
described below.
• Both
Users can submit these Jobs and Process Flows and view the output with the file viewer.
• Request
Users can submit these Jobs and Process Flows, but not view their output.
• Output
Users can view the output of these Jobs and Process Flows, but not request them.
The Usage column in the Assigned table signifies the setting for each Job and Process Flow.

Understanding the DBA User Group

The DBA User Group is created when you install Applications Manager. It has access to all Applications Manager
objects. Usually the Applications Manager administrator is assigned to the DBA User Group. You cannot edit or
delete this User Group. Whenever a User creates an object, it is automatically assigned to the DBA User Group.
The only objects you can assign/unassign to this User Group are Users. The DBA User Group is also required to
access certain areas of Applications Manager. These include:
• The Applications Manager Database Browser window used to browse tables, views, triggers, and procedures
in the Applications Manager database. For more information, see Browsing the Applications Manager Database.
• The RmiServer Config window used to:
• Assign Automation Engines to the RMI server that the current Automation Engine is served by.
• Add Automation Engines to the Automation Engine drop-down list on the Login window of the Automation
Engine you added them with.
For more information, see Accessing Multiple Applications Manager Instances from One Client.
• The Connections window used to:
• View which Applications Manager Users are logged into a User session
• Send broadcast messages
• View Agent connection information
• View RMI server information
• Activate an RMI server to support the Automation Engine
For more information, see Viewing User Connection Information and Sending Broadcasts and Viewing Server
and Agent Connection Information.
• The Clear RMI Errors option on the View menu on the Applications Manager Desktop to clear the RMI errors
without stopping the RMI server.
• The Audit and Email tabs of the Automation Engine/Local Agent. For more information, see Enabling
Applications Manager Auditing and Specifying Email Settings for the Automation Engine.
Users with the DBA User Group and Different User Options
Users with the DBA User Group may have different User Options assigned to them. For more information on User
Options, see Setting User Options.
Do Not Remove the DBA User Group from the SQLOPER User
When you install Applications Manager, the DBA User Group is assigned to the SQLOPER User. Do not unassign
the DBA User Group from this User or you will not be able to log into the Applications Manager client as the
SQLOPER User.
 Applications Manager 9.4.1

We highly recommend that you change the default password of the SQLOPER User, otherwise anyone can log
in as that User and have access to all the Applications Manager windows. Just make sure that your Applications
Manager administrators know the current password.

Understanding User Authorities

User Authorities are a special object type that control User access to the Applications Manager windows. You
cannot add, edit, or delete User Authorities like other Applications Manager objects. You can only assign them to
User Groups as shown in the image below. Different User Group access will be granted to a User, depending on
whether each User Authority is assigned to one or more edit User Groups or non-edit User Groups.

Adding Objects
User Authorities for Applications Manager objects must be assigned to an edit User Group if you want the Users
who are also assigned to that User Group to be able to add those objects to Applications Manager. For example,
Users that have the Jobs User Authority in an edit User Group will be able to add Jobs to Applications Manager. An
edit User Group (a User Group with the Edit box checked) is shown below.
 Applications Manager 9.4.1

Taking Actions on Tasks

In order to hold, kill, reset, or delete tasks, or to remove all predecessors for tasks in the Backlog, Users must have
the Explorer User Authority assigned to them in an edit User Group. If some Users only manage tasks in Explorer
and they never add, edit, or delete object definitions, you can create an edit User Group that only includes the
Explorer User Authority and assign it to them.
Windows the Explorer User Authority Gives Users
When the Explorer User Authority is assigned to a User Group, Users with that User Group will have access to the
following windows:
• Explorer
• Backlog Gantt View
• Forecast
• Graphical Forecast
Accessing All Other Operations Windows
It does not make a difference whether the Output, Requests, Export, or Import windows are assigned to an edit
or non-edit User Group. However, when you add the Export and Import User Authorities to a User Group, it is also
important to assign the IMPEXP Job to that User Group. Without it, Users cannot run exports and imports.

Assigning User Groups to an Object

Assigning Objects to a User Group discussed assigning objects to a User Group. But you also can assign User
Groups to an object. For example, you can assign a User Group to a Process Flow from the Process Flows
window. Because Applications Manager is object-oriented, there is no difference between assigning a User Group
to an object, or an object to a User Group.
If you cannot assign a User Group to an object when you have both the User Group and the object in one or more
of your roles, it may be because you have the User Group assigned to your User, but not to any of your User
Groups. Your Applications Manager administrator can remedy this by assigning the User Group to itself.
 Applications Manager 9.4.1

Procedure
To assign User Groups to an object:
1. From any object's definition window select the User Groups tab
In the image above the User Groups tab is selected for a Queue.
2. Select the User Groups you want to assign to the object.
Removing Objects from a User's Maintenance User Group
When an object is assigned to a User's Maintenance user group, that User cannot remove the object from that
User Group. If you need to remove an object from a User's maintenance User Group, you must be logged in as a
different User. For more information on Users and maintenance User Groups, see Defining Users.

Planning Your Security Set-up for Jobs and Process Flows

The table below shows several User Group assignments for Users of Jobs and Process Flows that include different
Edit authorizations, User Authorities, objects, and options.

If you want Users to be able to: Assign them to:

Add new Jobs and Process Flows to Applications One or more User Groups with Edit authorization
Manager. including the Jobs and Process Flows User Authorities.
One of these User Groups should be their maintenance
User Group.
One or more User Groups with or without Edit
authorization including all the objects that they will
assign to the Jobs and Process Flows they will add.
 Applications Manager 9.4.1

If you want Users to be able to: Assign them to:

View, edit, and delete select Job and Process Flow One or more User Groups with Edit authorization
definitions. including the Jobs and Process Flows they can edit and
delete. One or more User Groups with or without Edit
authorization including:
• The Jobs and Process Flows User Authorities.
• If Jobs will be created from an auxiliary window
for an Agent type such as OAE or PeopleSoft, the
Agents User Authority and the Agent object.
• Any objects assigned to the Jobs and Process Flows
that you want them to be able to select.
If a supporting object is selected in a Job or Process
Flow's field, and a User does not have access to
the supporting object, that field will be grayed out.
For example, assume the AWSQLP Program Type
is assigned to TEST_JOB. A User named Pat has
TEST_JOB in an edit User Group, but he doesn't have
the AWSQLP Program Type in any User Groups. Pat
can edit TEST_JOB, but he cannot change its Program
Type, because the field is grayed out for him (showing
AWSQLP as its selection).

View select Job and Process Flow definitions without One or more User Groups without Edit authorization
the ability to edit them or add new Jobs. including:
• The Jobs and Process Flows User Authorities.
• Jobs and Process Flows that these Users can view.
Additionally, these Users would need to not be assigned
to any User Groups with Edit authorization that includes
the items listed above.

Assign Jobs and Process Flows as Process Flow One or more User Groups with or without Edit
components. authorization including the Jobs and Process Flows
they can assign to Process Flows.
One or more User Groups with Edit authorization
including the Process Flows User Authority.

Request Jobs and Process Flows. One or more User Groups with or without Edit
authorization including:
• The Jobs and Process Flows they can request.
• The Requests User Authority.
Each of the Jobs and Process Flows that they can
request needs to have the Request or the Both Job/
Process Flow option checked in one or more User
Groups.
 Applications Manager 9.4.1

If you want Users to be able to: Assign them to:

View Job output. One or more User Groups with or without Edit
authorization, including:
• The Explorer or Output User Authority.
Each of the Jobs that they can view output for needs to
have the Output or the Both Job/Process Flow option
checked in one or more User Groups.
To view output on the Output window for tasks run by
other Users, they will also need the View Other Users'
Output User Option.
To view details in Explorer for tasks run by other Users,
they will also need the View Other Users' Tasks User
Option.

View task details in the Backlog without the ability to One or more User Groups with or without Edit
edit the task details. authorization, including the Explorer User Authority.
To view details for tasks run by other Users, they will
also need the View Other Users' Tasks User Option.

Edit tasks in the Backlog One or more User Groups with or without Edit
authorization, including the Explorer User Authority.
To edit tasks run by other Users, they will also need the
Edit Other Users' Tasks User Option.

Take actions on tasks in the Backlog One or more User Groups with Edit authorization,
including the Explorer User Authority.

Planning Your Security Set-up for Basic Objects

The table below shows several User Group assignments for Users of all objects except for Jobs and Process
Flows.

If you want Users to be able to: Assign them to:

Add new objects to Applications Manager. One or more User Groups with Edit authorization
including the User Authority for each type of object you
want the Users to be able to add.
One of these User Groups should be their maintenance
User Group.
One or more User Groups with or without Edit
authorization including all the objects that they will
assign to the objects they will add.
 Applications Manager 9.4.1

If you want Users to be able to: Assign them to:

View, edit, and delete select object definitions. One or more User Groups with Edit authorization
including the objects they can edit and delete.
One or more User Groups with or without Edit
authorization including:
• The User Authorities for each type of object you
want them to be able to edit and delete.
• All the supporting objects that are assigned to the
objects that you want them to be able to select.
If a supporting object is selected in another object's
field, and a User does not have access to the
supporting object, that field will be grayed out. For
example, assume the MONITOR Thread Schedule
is assigned to the BATCH Queue. A User named Pat
has the BATCH Queue in an edit User Group, but she
doesn't have the MONITOR Thread Schedule in any
User Groups. Pat can edit the BATCH Queue, but she
cannot change its Thread Schedule, because the field is
grayed out for her (showing MONITOR as its selection).

View select object definitions without the ability to edit One or more User Groups without Edit authorization
them or add new objects. including:
• The User Authorities of each object type you want
them to view.
• The objects you want these Users to view.
Additionally, these Users would need to not be assigned
to any User Groups with Edit authorization that includes
the items listed above.

Assign objects to other objects. One or more User Groups with or without Edit
authorization including the objects they can assign to
other objects.
One or more User Groups with Edit authorization
including:
• The User Authorities of each object type they will be
adding the objects to.
• The objects they will be adding these objects to.

Sample User Groups and Users

In this topic, sample User Groups and Users are described for programmers, operators, and end-users. They are
provided to help you begin thinking about how you want to set up User Groups for your system. You will need to
modify these samples to meet your needs.
General Guidelines
Below are some general guidelines that apply to User Groups.
• For each class of User (programmers, operators, etc.), create two User Groups: one with and one without Edit
authorization. You may find that you wish to create more than two User Groups for each User.
• Assign objects you want a User to edit to the User Group with Edit authorization.
• Assign objects you want a User to view, but not edit, to the User Group without Edit authorization.
• For each User, assign the User Group with Edit authorization as their maintenance User Group. This ensures
the User will have access to the objects they create.
Two User Groups are Better Than One
In general, setting up an edit User Group and a non-edit User Group for each type of User will give you adequate
flexibility in controlling a User's access to objects.
 Applications Manager 9.4.1

The User Group with Edit authorization would include objects you want the User to be able to edit. For example,
you might include the Jobs User Authority and several Jobs that programmers use. This would allow the
programmers to edit some existing Jobs, and create new ones. The User Group with Edit authorization would also
be assigned as the Maintenance User Group for the User. This would let the programmers edit any of the Jobs
they create.
The User Group without Edit authorization would include objects you want the User to view, but not edit. Using the
programmer User Group as an example, you would include the Jobs you want the programmer to view.

Programmer User Groups and Users

A programmer's key responsibility is creating Jobs and Process Flows. To create Jobs and Process Flows,
programmers need to create other objects such as Substitution Variables, Program Types, and Data Types.
Programmers must also be able to select, but not necessarily create additional objects including, Output Devices,
Logins, and Queues. You can give programmers the access they need using two User Groups: one edit, the other
non-edit (read-only).
Creating the Programmer User Group with Edit Authorization
You should create a User Group with Edit authorization for your programmers. This User Group could be named
PROGRAMMER_EDIT.
Once you create the edit User Group, you should assign User Authorities to it. By assigning User Authorities to an
edit User Group, Users who are assigned to the User Group will be able to access the corresponding window and
add that type of object.
Sample User Authorities that you may wish to assign to an edit User Group for your programmers include:
• Jobs
• Libraries
• Substitution Variables
• Notifications
• Explorer
• Process Flows
• Program Types
• Requests
• Message Templates
• Exports
• Applications
• Data Types
• Output Scans
• Reports
• Imports
Next, you would assign the existing objects that you wish to allow your programmers to edit including Jobs,
Process Flows, Substitution Variables, Data Types, and Calendars. In many cases, you would assign some, but not
all objects of a particular type.
Since the Export and Import User Authorities are assigned to this User Group, it is also important to assign the
IMPEXP Job. Without it, Users cannot run exports and imports.
The programmers will also need access to the objects they create. However, new objects will be taken care of
by assigning this User Group as the maintenance User Group for each programmer User. When a programmer
creates an object, it will automatically be assigned to the maintenance User Group.
Creating the Programmer User Group without Edit Authorization
You should create a User Group without Edit authorization for your programmers. This User Group could be named
PROGRAMMER_NO_EDIT.
Once you create the non-edit User Group, you should assign User Authorities to it. By assigning User Authorities
to a non-edit User Group, Users who are assigned to the User Group will be able to access the corresponding
window, but not be able to add that type of object (unless they also are assigned to one or more edit User Groups
with that User Authority).
Sample User Authorities that you may wish to assign to a non-edit User Group for your programmers include:
• Calendars
 Applications Manager 9.4.1

• Agent Groups
• Queues
• Logins
• Output Devices
• Agents
• Output Groups
Next, you would assign the existing objects that you wish to allow these Users to view and assign to other
objects. For example, a programmer will need to assign an Agent to a Job to complete the Job definition, but the
programmer does not have to create or edit Agents. Creating and editing Agents will probably be done by the
Applications Manager administrator.
Creating Programmer Users
You will need to create an Applications Manager User for each programmer. Once you create the Users,
you assign User Groups to them. In this example, you would assign the PROGRAMMER_EDIT and
PROGRAMMER_NO_EDIT User Groups to each User. The edit User Group which the programmers are assigned
to should be selected as the maintenance User Group for the Users. In this example, the maintenance User Group
will be PROGRAMMER_EDIT.
Next, you will assign User Options to each User. Sample User Options for programmers are listed below:
• Select Requestors
• Edit Other Users' Tasks
• Create Procedure SubVars
• Take Actions on Agents
• Set Task Name Suffixes
• Select Queues For Requests
• View Other Users' Output
• Receive RmiServer Error Broadcasts
For more information on User Options, see Setting User Options.

Operator User Groups and Users

An operator's key responsibility is monitoring system activity. To monitor the system, they need access to Queues,
Thread Schedules, and the Explorer window. Typically, an operator will not create or edit other objects, but they
may need to look at Jobs and Process Flows to troubleshoot problems.
Creating the Operator User Group with Edit Authorization
You should create a User Group with Edit authorization for your programmers. This User Group could be named
OPERATOR_EDIT.
Once you create the edit User Group, you should assign User Authorities to it. By assigning User Authorities to an
edit User Group, Users who are assigned to the User Group will be able to access the corresponding window and
add that type of object.
Sample User Authorities that you may wish to assign to an edit User Group for your programmers include:
• Queues
• Requests
• Thread Schedules
• Explorer
Next, you would assign all Queues and Thread Schedules to the User Group. The operators will also need
access to the objects they create. However, new objects will be taken care of by assigning this User Group as
the maintenance User Group for each operator User. When an operator creates an object, it will automatically be
assigned to the Maintenance User Group.
Creating the Operator User Group without Edit Authorization
You should create a User Group without Edit authorization for your operators. This User Group could be named
OPERATOR_NO_EDIT.
Once you create the non-edit User Group, you should assign User Authorities to it. By assigning User Authorities
to a non-edit User Group, Users who are assigned to the User Group will be able to access the corresponding
window, but not be able to add that type of object (unless they also are assigned to one or more edit User Groups
 Applications Manager 9.4.1

with that User Authority). Sample User Authorities that you may wish to assign to a non-edit User Group for your
operators include Jobs, Process Flows, and Reports. Next, you would assign all Jobs and Process Flows.
Creating Operator Users
You will need to create an Applications Manager User for each operator. Once you create the Users, you assign
User Groups to them. In this example, you would assign the OPERATOR_EDIT and OPERATOR_NO_EDIT
User Groups to each User. The edit User Group which the operators are assigned to should be selected as the
maintenance User Group for the Users. In this example, the maintenance User Group will be OPERATOR_EDIT.
Next, you assign User Options to each User. Sample User Options for operators are listed below:
• Edit Other Users' Tasks
• Take Actions on Agents
• Set Task Name Suffixes
• Select Queues For Requests
• View Other Users' Output
• Receive RmiServer Error Broadcasts
For more information on User Options, see Setting User Options.

End-User User Groups and Users

End-users generally submit tasks using the Requests window and view the output from the Output window. End-
users are the only Users who use the Output window to view output. All other Users view output from History in
the Explorer window. Unlike programmers and operators, end-users need only a single User Group without Edit
authorization.
Creating the End-User User Group without Edit Authorization
You should create a single User Group without Edit authorization for your end-users. This User Group could be
named END_USER_NO_EDIT.
Once you create the non-edit User Group, you should assign the Requests and Output User Authorities to it. Next
assign all Jobs and Process Flows that you wish the end-user to be able to request. If you want your end-users to
select an Output Device when they request tasks, you may also want to assign those Output Devices to the User
Group.
Creating Applications Manager Users for your End-Users
You will need to create an Applications Manager User for each end-user. Once you create the Users, you assign
the User Group to them. In this example, you would assign the END_USER_NO_EDIT User Group to each User.
Next, you will assign User Options to each User. Sample User Options for end-users are listed below:
• View Other Users' Output
• Set Task Name Suffixes
For more information on User Options, see Setting User Options.
Default Files on the Output Window
In order for the application output or report files of a Job to be listed by default in the Output window, the Job's
Output function setting must be set to LOG. If output files are not displayed by default in the Output window, end-
users can query for them.
If you do not have Users who access the Output window, you should never set an Output function setting to
LOG. Doing so will slow the client load time for every User on your system.

Defining Database Logins

If a program run by a Job requires access to a database, you must create an Applications Manager Database
Login. The Applications Manager database Login object protects the actual Database Login and password while
giving users access to the database. A Login's encryption flag is set by the system when you update or add a
Login. After you create a Login, other users can assign it to Jobs and Process Flow components.
Applications Manager User Groups control access to Logins. If you do not have access to them, see your
Applications Manager administrator.
For Rapid Automation Agent documentation including Agent-specific Login object tabs, see the the following.
• The Banner Rapid Automation Agent for Local Clients Documentation
 Applications Manager 9.4.1

• The Banner Rapid Automation Agent for the Automic Web Interface Documentation
• All other Rapid Automation Documentation
Creating an Oracle Database Login
The procedure for creating Logins is different for each Login type. This example describes how to add an Oracle
Database Login:
1. From the Logins Selector window, click New.
Applications Manager opens the Select Login Type window shown below.

2. Select the ORACLE Login type and click OK.

The Login type you select determines which fields are available for the on the Logins window. For information
on other Login types, see your related Applications Manager interface or extension documentation.
3. Complete the fields using the information below.
• Name
The Login name. If you need to create two or more Logins with the same name (for example, you use the
same Login name on two databases), you will need to distinguish the names from one another (Login names
must be unique within Applications Manager).
To create unique names for Applications Manager, append an '@' character followed by any number of
characters (up to 32 total) to the end of a Login name. The '@' and characters after it will be stripped off
before the name is passed to a Job. For example, if Oracle databases running on two hosts (sun1 and dg1)
 Applications Manager 9.4.1

both use the same Login name, add '@sun1' and '@dg1' to the Login names in order to distinguish them
from one another: sqloper@sun1 and sqloper@dg1.
• Type
Specifies the type of Login that was selected on the Select Login Type window. ORACLE will be displayed
for Oracle Logins.
• Password
The password.
Warning: You cannot edit the password for the Oracle Database Login created when you installed
Applications Manager on this screen. For information on changing the password for the default Oracle
Database Login, see Changing the Default Oracle Login and Password in Applications Manager .
If you change the password for any other Logins, you do not need to stop and restart processes.
• Service Name
The Oracle service name. Used only with a local database residing on the same machine as the Applications
Manager database or a JDBC connection.
• Network Alias
You must enter a Network alias if the database resides on a different machine than Applications Manager.
You can also use a Network alias to identify a local database. For example, a SQL*Net Network alias for an
Oracle database.
• Host
The IP address of the Login. Used to define the Login for JDBC use.
• Port
The port number used if this Login will evaluate dynamic Substitution Variables, Data Types, or Reports in its
database. To evaluate dynamic Substitution Variables, Data Types, or Reports on an Oracle database other
than the Applications Manager database, the Oracle Sid, Host name, and Port must be defined.
You do not need to define a port for the default Database Login created when you install Applications
Manager.
• Encrypted
Applications Manager automatically encrypts the password and checks the Encrypted field when you click
OK. You cannot change the Encrypted setting.
Testing the Connection
When you specify a Name, Password, Oracle Sid, and Host for an Oracle Login, you can test the connection
using the Check button.
The Check button uses regular FTP (not SFTP) to test the connection. If your server requires SFTP, this may result
in a failed test connection.

Specifying JDBC Requirements for Logins

To evaluate dynamic Substitution Variables, Data Types, or Reports on a database other than the Applications
Manager database, the Login object must be defined for JDBC use. The required fields for each Login type to allow
JDBC use are described below.
OAE
Required fields for OAE Logins.

Required fields Example

Service Name sun28_817

Host Oracle.internal.com

Port 1521
 Applications Manager 9.4.1

JDBC Connection Format

jdbc:oracle:thin:@<Host>:<Port>:<Oracle Sid>

ORACLE
Required fields for ORACLE Logins.

Required fields Example

Service Name PTSYS

Host Peoplesoft.internal.com

Port 1521

JDBC Connection Format

jdbc:oracle:thin:@<Host>:<Port>:<Oracle Sid>

ORACLE RAC
Required fields for ORACLE RAC Logins

Required fields Example

Name testrac

RAC String RAC String (you should be able to copy the tns entry
starting with the following:
"(DESCRIPTION"):
(DESCRIPTION_LIST = (FAILOVER = TRUE)
(LOAD_BALANCE = FALSE)
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux1) (PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.am.com)
(INSTANCE_NAME = awrac1) ) )
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux2)
(PORT = 1521)) (CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.am.com)
(INSTANCE_NAME = awrac2) )

RAC Flag This value will activate the connection as JDBC.

Y
 Applications Manager 9.4.1

SQLSRVR
Required fields for SQLSRVR Logins.

Required fields Example

SQLSRVR Sid Sales_and_Marketing

Host sales.internal.com

Port 1344

JDBC Connection Format

jdbc:jtds:sqlserver://<Host>:<Port>/<SQLSRVR Sid>

SYBASE
Required fields for SYBASE Logins.

Required fields Example

SYBASE Sid Syb_db

Host Sun.internal.com

Port 1700

JDBC Connection Format

jdbc:jtds:sqlserver://<Host>:<Port>/<SYBASE Sid>

Changing the Default Oracle Login and Password in Applications Manager

When Applications Manager is installed, a Database Login is created by default for logging in to the Applications
Manager database account (the repository). The Database Login is usually named the same as the database
account name you provide during the installation process.
There are three places the Oracle Login is stored in Applications Manager:
• The so_ids table in the database.
• The Masters.properties file in the data directory.
• The ISAIMPORT file in the map directory.
All paths are relative to the Applications Manager home directory.
Procedure
To change the Oracle password in Applications Manager:
1. Stop all the Applications Manager processes.
For directions on stopping and starting the processes, see the Installation Guide.
2. Before changing the password on the Oracle side, change the name/password for your Database Login in
Applications Manager. If the password is already changed, you will need to go into SQL*Plus and update the
so_ids table. To change the Database Login, issue the following SQL statements. You may not need to set a
connect string.

update so_ids set so_login = '<new_DB_login>' where so_login = '<old_DB_login>';

 Applications Manager 9.4.1

update so_ids set so_passwd = '<new_DB_password>' where so_login = '<new_DB_login>';

update so_ids set so_encrypted = 'N' where so_login = '<new_DB_login>';
O~DBLOGIN~<Login name>

3. Change the password in Oracle.

4. Edit the Automation Engine line in the Masters.properties file in the data directory. The Automation Engine
line uses the format <master name>=<IP address> <Login name> <port> <service name or PDB service
name for Oracle 12c and above> <Encrypted Y/N> ENC:<encrypted User name>\=\= ENC:<encrypted
password>\=\=.
• Change the Y for encrypted to N.
• Replace the encrypted User name (ENC:<encrypted User name>=/=/) and password (ENC:<encrypted
password>=/=/) with an unencrypted User name and password.
5. If the Database Login name was changed, edit the O~DBLOGIN~ line in the ISAIMPORT.dat file in the map
directory. A sample is shown below:

N~NODE~<Agent name>

6. Start the Applications Manager processes.

7. From the command prompt, issue the following command:

Awexe id_recrypt

Configuring Oracle RAC

This topic is an overview of how to configure Applications Manager to work with Oracle RAC. This method has
been tested in house with an Oracle RAC running on 10.0.3.
There are two steps for configuring RAC:
1. Configuring the tnsnames.ora file.
2. Configuring the RMI Server.
Configuration of the tnsnames.ora File
The Applications Manager processes connect to the Oracle database on the Automation Engine machine and
handle all database transactions issued by Agents. In an Oracle RAC environment these processes need to be
configured to run through SQL*Net. This can be done by either:
• Putting the TNS Name into the Oracle Login for the Applications Manager database.
• Setting the variable TWO_TASK to the TNS Name and placing this in the sosite file.
The TNS Name definition for the Oracle RAC should have all the parameters set for the databases instances
Applications Manager can connect to. Here is an example:

ORCLFAILOVER =
(DESCRIPTION_LIST =
(FAILOVER = TRUE)
(LOAD_BALANCE = FALSE)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux1)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.automic.com)
 Applications Manager 9.4.1

(INSTANCE_NAME = awrac1) ) )
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux2)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.automic.com)
(INSTANCE_NAME = awrac2) ) ) )

Configuring of the RMI Server

The RMI Server is the process that servers information to the Java client and runs the Applications Manager
Automation Engine. It connects to Oracle instances through JDBC over SQL*Net.
To configure this for Oracle RAC you need to add an entry into the Options.properties file on the Automation
Engine machine.
The location for the Options.properties file is:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

The entry is OracleRAC and it is nearly identical in content to the tnsnames.ora entry. It should contain all the
information for the database instances that Applications Manager can connect to. Here is an example of the same
connection above as it would appear in the Option.properties:

OracleRAC= (DESCRIPTION = \
(load_balance=off) \
(failover=on) \
(ADDRESS_LIST = \
(ADDRESS = (PROTOCOL = TCP)(HOST = vip-linux1)(PORT = 1521)) \
(ADDRESS = (PROTOCOL = TCP)(HOST = vip-linux2)(PORT = 1521)) \
)\
(CONNECT_DATA = (SERVICE_NAME = awrac.appworx.com)))

Note that the slashes at the end of each line are required so the entry is interpreted by the RMI Server as one
continuous line. Also use on and off rather than true and false for load_balance and failover.
Also, setting this the OracleRAC line will override the DB_IP, DB_PORT, and DB_SID in the awenv.ini file.
Load Balancing
When using Applications Manager on RAC, your DBA will need to disable load balancing on both the client side (in
tnsnames.ora) and server side. To turn off load balancing for the server, you can use one of these methods:
 Applications Manager 9.4.1

• Use the ALTER SYSTEM statement to dynamically alter your Oracle Database instance. For example:

SQL> show User

USER is "SYS"
SQL> alter system set remote_listener ='';
System altered.

After you do this you will need to restart Applications Manager processes with stopso and startso commands
so that connections will go to only one RAC node.
• Back up and edit the init.ora file for each instance in the RAC setup and remove only the REMOTE_LISTENER
lines. Do not remove any other lines. This will require a restart of Oracle instances and Applications Manager
processes.
The reason why we need load balancing to be off is that there are known issues with DBMS pipes. Our processes
'sleep' and 'wake up' on DMBS Pipes. Pipes are instance-specific, so if Applications Manager processes are
balanced across multiple instances, then wake-ups issued by one process might not activate the target process.
For example, the master might sleep on one of the RAC nodes, but the wake-up happens on another node and so
the master continues to sleep. Processes will wake up eventually, but this is not ideal because of performance.
Failover
RAC failover will still work when load balancing is off (when remote_listener is set to nothing). The
remote_listener parameter is used mainly for load balance situations. When remote_listener is set to nothing,
failover will still work provided you have a LOCAL_LISTENER for each instance in the RAC setup and the
tnsnames.ora RAC entry on the clients have two addresses in an ADDRESS_LIST.
Because some of the database processes might have been issuing a database transaction at the time of the
failure, it is possible to lose a transaction or two during this switch. This might result in a Job going into a DIED
status or a node going into BUSY status. Clients should be connected immediately, but there will be an error and a
time delay in Automation Engine processing. You might see these errors during the switch:

ErrorMsg: AwE-5001 Database Query Error (7/12/07 6:38 PM)

Details: No more data to read from socket
aw5.aw_wait_obj_changed
ErrorMsg: AwE-5001 Database Query Error (7/12/07 6:38 PM)
Details: No more data to read from socket
aw_web_api.aw_inc_update
ErrorMsg: AwE-9999 Internal error (7/12/07 6:38 PM)
Details: Io exception: Broken pipe
null
ErrorMsg: AwE-5001 Database Query Error (7/12/07 6:38 PM)
Details: Closed Connection
getConnection

After these errors everything should switch over. If you'd like, you can check connections for sessions like this:

SQL> show User

USER is "SYS"
> select inst_id
,sid
,audsid
,username
,program
 Applications Manager 9.4.1

from gv$session
where username='APPWORXSCHEMANAME';

Example ORACLE_RAC Login Values

• Name
testrac
• Type
ORACLE_RAC
• Password
secret
• RAC String
You should be able to copy the tns entry starting with:

"(DESCRIPTION"):
(DESCRIPTION_LIST = (FAILOVER TRUE)(LOAD_BALANCE = FALSE)
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux1) (PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.am.com)
(INSTANCE_NAME = awrac1) ) )
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = vip-linux2)
(PORT = 1521)) (CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = awrac.am.com)
(INSTANCE_NAME = awrac2) ) )

ORACLE_RAC Login Type

The main intended use of the ORACLE_RAC Login type is for Subvars with JDBC connections. The
ORACLE_RAC Login is not intended to be assigned to Jobs that require SQL*Net connections and it has
Applications Manager-imposed character limitations for the RAC string value.
If you need to use a RAC Login for a Job that needs a SQL*Net connection or a net_connect string, add the
full RAC entry to the local machine's tnsnames.ora and define a regular Applications Manager ORACLE Login
object with a connect string. That should use the RAC information at the Oracle layer and allow Oracle to direct the
connection to the correct instance.

Working with the Automation Engine and Agents

An Agent is an instance of Applications Manager. Agents are installed on each machine where tasks are executed.
An Agent can be an Automation Engine's Local Agent, or a Remote Agent. The Automation Engine schedules and
controls task execution on all the Agents assigned to it. Agent Groups distribute the load between Agents on two or
more machines.
With Applications Manager Automation Engines and Agents, you can control tasks on multiple machines from any
Applications Manager client. A sample architecture diagram is shown below.
 Applications Manager 9.4.1

The Applications Manager Automation Engine resides on a server and launches local tasks via its Local Agent.
Remote Agents reside on other servers but receive commands via the Automation Engine. For the Automation
Engine/Agent relationship to work, Applications Manager Agent software must be installed on all the machines you
wish to control. The Applications Manager database must reside on a single machine.
How Applications Manager Runs Tasks
When the Automation Engine determines that a task should be executed, it submits it to an Applications Manager
Queue. The Agents poll the Queue. When an Agent finds a task that it should run, it pulls that information from the
Queue and runs the task. When the task completes, it sends status information back to the Automation Engine.
What to Consider When Planning Automation Engine/Agent Installations
An Automation Engine controls and monitors the execution of tasks on its Agents. This gives you centralized
control over several machines. You can have any combination of Automation Engines and Agents. For example, an
Agent reporting to one Automation Engine can reside on a machine containing another Automation Engine.
When determining the number of Automation Engines and the number of Agents assigned to each Automation
Engine, you should consider the reliability of your machines and network. If the Automation Engine machine goes
down, tasks will not be launched on any of the Automation Engine's Agents. If an Automation Engine loses network
communication with an Agent, tasks will not be launched on the Agent. However, when the Automation Engine is
operational again, or network communications are restored, Applications Manager will resume operations at the
point they were interrupted.
SSL Encryption Between Automation Engine, Agents, and Clients
There is now SSL encryption between Applications Manager Automation Engines, Agents, and clients.
Basic Steps for Installing an Applications Manager Remote Agent
The basic steps for installing a Remote Agent are:
1. Define the Remote Agent object in Applications Manager.
 Applications Manager 9.4.1

2. Create a User object.

3. Install the Applications Manager Remote Agent software.
4. Start the Network Listener Service (for Windows).
5. Verify the installation.
Step 1 is described in Defining Remote Agents. Steps 2-5 are described in the Installation Guide.
Using Agent Groups
Agent Groups distribute the load between Agents on one or more machines. You create Agent Groups and assign
Local and Remote Agents. the diagram below shows the relationships between Agents and Agent Groups.

You specify an Agent or Agent Group when you define a Job. When you specify an Agent or Agent Group for a Job,
you are telling Applications Manager where the program is located and where it will be run. Applications Manager
will run the program on the first available Agent in an Agent Group.
Turning on Audit
If you have the DBA User Group assigned to you, you will see an Audit tab on the Agents window for the
Automation Engine/Remote Agent. From it you can turn on Applications Manager auditing. Applications Manager
auditing allows you to see who has edited objects. For more information, see Enabling Applications Manager
Auditing.

Defining Remote Agents

During install, Applications Manager creates an Automation Engine and its Local Agent. You can add Remote
Agents by adding an Agent object in Applications Manager and running an install script. an Applications Manager
Remote Agent is used to run tasks on a machine that does not include the Applications Manager Automation
Engine.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Agents. If you do not have access to them, see your
Applications Manager administrator.
For Rapid Automation Agent documentation including Agent-specific Login object tabs, see the the following.
• The Banner Rapid Automation Agent for Local Clients Documentation
• The Banner Rapid Automation Agent for the Automic Web Interface Documentation
• All other Rapid Automation Documentation
Adding Remote Agents
To add a Remote Agent object:
1. From the Agents Selector window, click New.
Applications Manager opens the Select agent type window shown above.
2. Select STANDARD to define an Applications Manager Remote Agent and click OK.
3. Complete the fields using the information below.
• Name
The name can be up to 30 characters long. If you install two or more Remote Agents on a machine, do not
give them the same name (even if they report to different Automation Engine instances). The following are
reserved words that cannot be used for Automation Engine or Agent names; ALL, APPWORX, AWCOMM,
AGENTSERVICE, AWAPI, RMI, RMISERVER, AGENT, and MASTER.
• Description
A description of an Agent can be up to 30 characters long.
• IP address
The IP address or DNS name.
• Sleep time
 Applications Manager 9.4.1

Defines how many seconds (10 to 1,000) Applications Manager will wait between processing cycles. It also
controls how often conditions are evaluated.
• CPU Limit
Defines the percentage of CPU usage at which Applications Manager will spawn no new tasks. When an
Agent reaches its CPU limit it will go into a CPU WAIT Agent status. Tasks waiting to run on an Agent that
has reached its CPU limit will go to an AGENT WAIT status. The default it 80% for newly created Agents
or 99% for Agents that were upgraded from a version of Applications Manager before this feature existed.
You can see actual CPU usage percentages for Agents in the Cpu column on the Agent SUMMARY on the
Explorer window. The CPU usage is updated about once every minute for each Agent and the Automation
Engine.
• Type
This non-edit field specifies the type of Agent you are defining (Oracle Applications, PeopleSoft, Standard,
etc.).
• Thread Schedule
Sets the maximum number of concurrent tasks that can run on the Agent at one time in all Queues. For
information on defining Thread Schedules, see the User Guide.
Editing the Thread Schedule of the Automation Engine/Local Agent from this field will change the setting for
only the Local Agent.
Thread Schedules can be changed for the Automation Engine and Agents from the Explorer window.
• Environment Variables
Optionally specify one or more Environment Variables as a single Applications Manager object. For
information on defining Environment Variables, see the Development Guide.
• OS type
Indicates whether the operating system used on the Agent. The OS types are UNIX and Windows
• Output directory
Specifies the directory Applications Manager writes output files to for Jobs run on this Agent. The default
value for this field is automatically filled in when you select an operating system from the OS type field.
This field may be up to 32 characters long. If you enter a new directory here, be sure it exists and that
Applications Manager has read/write permissions to it.
The directory specified here can be overridden for Jobs if a directory is entered in the Output Directory field
on:
• A Job's Output tab.
• The Users window.
If an output directory is specified for both the Job and the User, the output directory of the User will override
the Job setting.
• User
The operating system User for the Agent. The User selected determines the Awexe range assigned to the
Agent. Be sure your Agents are assigned to a User with the full Awexe range, which is 1000-9999. For
information on setting the Awexe range, see Defining Users. Users assigned to a Remote Agent require an
Awexe range for the Agent to start.
This User should never be SQLOPER.
• Active
When unchecked, the status of the Agent will be INACTIVE. All tasks in the Backlog and newly submitted
tasks to the Agent will go to History with a status of INACTIVE.
• Agent debug
When checked, Applications Manager creates an AgentService.debug file in the Agent's debug directory.
The AgentService.debug file is also created when debug=true is set in the Agent's awenv.ini file. You
can also turn on debug for all Agents by clicking the Agent check box under the Debug menu on the About
Applications Manager window. For more information on the debug settings on the About Applications
Manager window, see Setting Client, Server, Oracle Trace, and All Agent Debug.
• Use Task Count Load Balancing vs. CPU%
When checked, this Agent will consider the number of tasks in the Backlog compared with it's Thread
Schedule's max threads rather than the actual CPU usage for load balancing when this Agent is included in
 Applications Manager 9.4.1

an Agent Group. We recommend you keep this box unchecked. By load balancing based on CPU usage,
Applications Manager takes into consideration processing of all Applications on the Agent machine, including
things run outside of Applications Manager.
Editing Agents
You can edit Remote Agents from the Applications Manager GUI. You can also edit the Automation Engine and
its Local Agent. The Automation Engine and its Local Agent are represented as a single object in the Applications
Manager GUI. When editing the Automation Engine and it Local Agent, you can set Automation Engine options. For
more information, see Setting Automation Engine Options.
Defining Multiple Agents on the Same Instance
To define multiple Agents on the same instance, simply create additional Agent objects with the same IP address
and User name. You will only need to run the Agent install the first time. The additional Agents will run under the
original Agent's processes.
If you choose to run an install for a second Agents on a machine, the user name and IP address cannot both be the
same as the first Agent.
Configure Applications Manager Main Window Color
You can define a specific color for different deployments of the Applications Manager. This will help you identify
which server you have logged in. For example, you might want to set different colors for development and
production environments.
To define a color for the Applications Manager main window:
1. In the Applications Manager, go to Object Admin > Administration > Agents.
2. Select Master's Agent.
3. Click Edit.
4. Go to Automation Engine Options > Theme.
5. Select the desired color.
6. Click Apply.
7. Click OK.

Specifying Output File Names

You can specify more meaningful output file names on an Agent. The method for specifying output file names
differs depending on the Agent type.
• Application Agents: You use the SYSTEM_OUTPUT_NAME setting in the Automation Engine's awenv.ini file
for each Agent.
• Applications Manager standard Agents: You write a short SYSOUT script in the Agent's exec directory.
Specifying the File Names in the awenv.ini File for Application Agents
For all application Agents, including OAE and PSE, you rename the system output file and the report file name with
entries in the awenv.ini file in the Automation Engine's site directory. Use the SYSTEM_OUTPUT_NAME setting to
rename the standard output file (the o file for Program Types that ship with Applications Manager).
The SYSTEM_OUTPUT_NAME setting can include replacement variables, Substitution Variables, and
Environment Variables. To apply them to all the Automation Engine's application Agents, put them under the
[default] section as shown below.

[default]
SYSTEM_OUTPUT_NAME=$AW_HOME/training/out/{run_id}_{task}.txt

Once entered, the SYSTEM_OUTPUT_NAME setting will not take effect until you stop and re-start the
AgentService process. To stop and restart processes, you must start by setting the new environment. To set the
environment:
1. Go to the $AW_HOME/site directory (%AW_HOME%\site for Windows).
 Applications Manager 9.4.1

2. Issue the following command:

. sosite

If you get an sosite not found error, try this command:

. ./sosite

After issuing the command, you should be returned to the command prompt where you can stop and re-start the
AgentService process with the following commands:

stopso agentservice
startso agentservice

Creating a SYSOUT Script for Standard Applications Manager Agents

You can write a short SYSOUT script (sysout.bat in Windows) to create more meaningful output file names for
standard Applications Manager Agents. For example, you can use the script to add the name of the Job that
produced the output to the beginning of the file names. You create the SYSOUT script in the Agent's exec directory.
The following SYSOUT script adds the Job name and run ID number to the names of the output files for an Agent.
For the log file, it also adds log to the end of the name. In the example below, file is the Environment Variable that
holds the name of the output file generated by the program, and stdout is the Environment Variable that holds the
name and full path of the o log file.

UNIX
file=$module.$jobid
stdout=$AW_HOME/training/out/$module.$jobid.log
Windows
set file=%module%.%jobid%
set stdout=%AW_HOME%\training\out\%module%.%jobid%.log

In previous versions of Applications Manager, the seq_no variable was used to rename output files. The seq_no
variable is no longer valid for renaming output. Be sure to use jobid.
With the above SYSOUT script in place, output file names for a Job called EMPLOYEES would look like the
following:
UNIX

Without SYSOUT With SYSOUT

b.3256.00 EMPLOYEES.3256.00

o3256.00 EMPLOYEES.3256.00.log

Windows

Without SYSOUT With SYSOUT

o3256.00.lis EMPLOYEES.3256.00.lis

o3256.00.log EMPLOYEES.3256.00.log
 Applications Manager 9.4.1

Setting Automation Engine Options

The Automation Engine and its Local Agent are represented as a single object in the Applications Manager GUI.
You can specify the several options for the Automation Engine using the Automation Engine Options tab shown
below and its sub-tabs.

Setting the Automation Engine's Time Zone

You may have tasks that you want to run at a particular time in a different time zone. You do this by making a
selection from the Time zone field on the Schedule tab for a Job or Process Flow. To do this, you have to select
the time zone for the Automation Engine, so Applications Manager will know how many hours to shift its start time.
To set the time zone for the Automation Engine.
1. Select a time zone from the Time zone field.
Select the standard time option if your computer does not adhere to daylight savings time. For example PST for
Pacific Standard Time.
UTC refers to the Universal Time Coordinate, which is used for the synchronization of computers on the
Internet. For information on selecting time zones, see the How Time Zone Shifts are Calculated subheading
below.
2. In the awenv.ini file located in the site directory, remove the TZ line. An example is shown below:

TZ=EST

3. Run awinstall from the home directory and choose option 3 to upgrade (or re-run the Windows install and select
upgrade). When you are prompted for your time zone, put in the correct time zone number.
 Applications Manager 9.4.1

4. After the install finishes, check the awenv.ini file. There will be a new time zone line like the example below:

TZ=CST

Warning: If you change the Automation Engine's time zone from a value to 'No selection', any Process
Flows with time zones set will lose their time zone settings.

How Time Zone Shifts are Calculated

The table below lists all defined time zones, showing when shifts occur and the method used to determine them.
below, the numbers in the Method column stand for the following:
0 - Standard Time with no changes.1 - The last Sunday in October at 2 A.M., the first Sunday in April at 2 A.M.2 -
The last Sunday in October at 1 A.M., the last Sunday in March at 1 A.M.

Time zone Description Method Shift

JST UTC+09 Japan 0 9

CCT UTC+08 China Coast 0 8

WAST UTC+07 West Australian 0 7

ZP6 UTC+06 Chesapeake Bay 0 6

EET UTC+02 Eastern European 0 2

CET UTC+01 Central European 0 1

MEST UTC+01(D2) Central 2 1

European

UTC UTC/GMT Greenwich 0 0

Mean

BST UTC(D2) British Summary 2 0

WAT UTC-01 W. Africa/Cape 1 -1

Verde

AT UTC-02 Azores Std. Time 1 -2

C UTC-03 Brazil Std. Time 1 -3

AST UTC-04 Atlantic Std. Time 0 -4

ADT UTC-04(D1) Atlantic DST 1 -4

EST UTC-05 Eastern Std. Time 0 -5

EDT UTC-05(D1) Eastern DST 1 -5

CST UTC-06 Central Std. Time 0 -6

CDT UTC-06(D1) Central DST 1 -6

MST UTC-07 Mountain Std. 0 -7

Time

MDT UTC-07(D1) Mountain DST 1 -7

 Applications Manager 9.4.1

Time zone Description Method Shift

PST UTC-08 Pacific Std. Time 0 -8

PDT UTC-08(D1) Pacific DST 1 -8

YST UTC-09 Yukon Std. Time 0 -9

YDT UTC-09(D1) Yukon DST 1 -9

AHT UTC-10 Alaska/Hawaii Std. 0 -10

AHDT UTC-10(D1) Alaska/Hawaii 1 -10

DST

Specifying the Automation Engine's Login Type

The Login specified in the Login type field is used for Jobs with Automation Engine Setting selected on their
Executions Options tab. There are two options:
• Jobs: The task runs under the Job's Login (unless the Job definition calls for the User's Login to be used).
• Users: The task runs under the User's Login (unless the User definition is set to 'No selection', in this case
Applications Manager will use the Job's Login). This option is useful if Users have different views of a database.
For more information, see Defining Users.

Setting Debug Automation Engine Options

The following Automation Engine options are selectable from the Debug sub-tab:
• Log Locks Encountered
Inserts records into appworx_errors table whenever a row in the Backlog is locked when Applications Manager
tries to update the same row.
• SQL Trace Debug
Turns on Oracle's SQL trace option - the results are in the oracle user log's directory. This should never be done
except when advised by Applications Manager product support.
• Enable TRUE condition debugging
Sets condition debugging only when the condition evaluates to true. For more information on debugging, see
Debugging the awcomm and awnetex C Processes.
• Enable full condition debugging
Sets full condition debugging. For more information on debugging, see Debugging the awcomm and awnetex C
Processes.
Turning condition debug on in the Applications Manager client will return the same information as setting the
CON|ALL in the awenv.ini file. The debug code will be written to the Automation Engine's RmiServer.log file.

Setting Explorer Automation Engine Options

The following Automation Engine options are selectable from the Explorer sub-tab:
• Use job max revisions
When you define a Job, you can specify the Max # of revisions of the output from the Job that Applications
Manager will save. Select this option to use that setting.
• Automatically assign new user group objects to themselves
Automatically assigns new User Groups objects to themselves at the time they are created.
• Enable auditing of backlog changes
Adds audit changes made in the Backlog to the aw_audit_reports_table database table. If you want to track
changes to conditions or prompts for reset tasks in the Backlog, then you should enable Backlog auditing.
Audit data is purged by running the PURGE_AUDIT_HISTORY Job. For more, see Enabling Applications
Manager Auditing.
• Allow aborted task to block single threaded queue
 Applications Manager 9.4.1

If a Queue has a Thread Schedule with 1 set in its Max Threads field, you will only be able to run one task at
a time through that Queue. When a Queue includes a Thread Schedule with 1 max thread, it is referred to as a
single-threaded Queue.
If this option is selected, an aborted task with the Stay in Queue on Abort option set will occupy the Queue's
only thread. No other tasks will be allowed to run through the Queue until one of the following occurs:
• The aborted task is deleted.
• The aborted task is reset and run to completion.
This option only applies to single-threaded Queues. It does not allow aborted tasks in the Backlog to occupy a
thread for Queues with a Thread Schedule that has more than one max thread.
• Allow deleted status to satisfy Success since last run
The Success since last run predecessor link type requires that a predecessor succeeds since the last time a
task ran. With this option checked, a deleted predecessor also satisfies the requirement.
• Schedules submitted as a group
Prevents all scheduled tasks from running when a task has Subvar problems. The default behavior when this
option is not checked is to raise an exception for the task with Subvar problems, but run all other scheduled
tasks.
• Disable initial predecessor inheritance
Disables predecessor links from Process Flow components to their successor Process Flow components when
the predecessor components are skipped. The successor tasks will be eligible to run when the Process Flow is
initiated, unless they have predecessor links to other tasks.

Setting Password Automation Engine Options

The following Automation Engine options are selectable from the Password sub-tab:
• Do not require awrun passwords
Allows you to use the awrun utility without a -z <password> argument.
• Disable user after 3 consecutive failed login attempts
Unchecks the Active box for a User if they enter the wrong password three consecutive times when logging into
the Applications Manager client.
• Force password change on new users
Forces Users to change their password the first time they log into Applications Manager.
• Force password to contain both alpha and numeric characters
Forces Users to include both alpha and numeric characters in their User password.
• Require password length of 6 characters
Forces Users to include at least six characters in their password.
• Disable clearing of login passwords on re-login
Remembers User passwords on the Login window. When you log out and back into a client session by
selecting Re-login from the File menu on the Applications Manager desktop.
• Force password change if reset by another user
Forces Users to create a new password after they log in for the first time with a new password.
• Allow requests from non active users
Assures that the OAE Agent will not fail when capturing a task with an inactive User.

Setting Process Flow Automation Engine Options

The following Automation Engine options are selectable from the Process Flows sub-tab:
• Insert components into process flow's queue
Sets Process Flow components to run on the Queue selected for the Process Flow, rather than the Queue
selected in their Job definition.
• Defer schedules on startup
Defers all scheduled tasks while the Automation Engine is stopped.
• Use virtual day for process flow component days of week
 Applications Manager 9.4.1

Specifies Process Flow component days by the virtual workday.

• Always evaluate subvars in process flow prompts at component run times when scheduled
Evaluates plain Subvars (that is Subvars without a Login) assigned to prompts in Process Flows when each
component runs rather than when the Process Flow goes to an INITIATED status. Having this option checked is
not recommended.
Changing this option requires you to stop and restart the RmiServer process. For information on stopping and
starting processes, see Starting and Stopping Automation Engine and Agent Processes.

Specifying LDAP Settings

If the Enable LDAP box is checked, the Applications Manager will use the LDAP authentication settings.
LDAP information is defined on the LDAP tab for the Automation Engine shown below.

If the Enable LDAP box on the LDAP tab is checked, the Applications Manager will use the LDAP authentication
settings described below.
• Java JNDI Factory class
Java JNDI Initial Context Factory class.
• URL
The URL of the LDAP server.
• Distinguished name (dn)
The distinguished name. For example: dn:uid={uid},ou=people,dc=am,dc=com
• Authentication mechanism
Value queryServer causes LDAP to be queried for authentication mechanisms.
• SSL Enabled
Enables SSL.
• Keystore path
Sets an LDAP keystore path.
• Keystore password
Specifies the LDAP keystore password.
To test the LDAP settings, click the Test LDAP Connection button.
For detailed descriptions of these fields, see your LDAP documentation.

Using Active Directory

There are a number of configuration files that need to be created in order for Applications Manager to interface
correctly with Active Directory.
To set up Active Directory for Applications Manager:
1. Create an AM_GSSAPI.conf file in the Automation Engine's AW_HOME directory. This tells Java which
authentication mode to use for LDAP. Sample code from a AM_GSSAPI.conf file is shown below:

com.appworx.server.ldap.LDAPAppworxAuthentication
{ com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=TRUE; }
;

If you have the Applications Manager installed on Windows, and you use an authentication method of GSSAPI,
you may need to add javax.security.auth.useSubjectCredsOnly to your AM_GSSAPI.conf file to ensure full
credentials are passed as shown below:

com.appworx.server.ldap.LDAPAppworxAuthentication
 Applications Manager 9.4.1

{ com.sun.security.auth.module.Krb5LoginModule required client=TRUE

useTicketCache=TRUE javax.security.auth.useSubjectCredsOnly=TRUE; }
;

For more information, see your LDAP documentation.

2. Create a krb5.conf file in the Automation Engine's AW_HOME directory. This configures the settings for the
Active Directory server. It also configures the log file location. A sample krb5.conf file file is shown below. Be
sure to change the realm and server names, which are in shown in bold below, to your correct settings:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
ticket_lifetime = 24000
default_realm = AUTOMIC.COM
default_tgs_enctypes=des-cbc-crc
default_ktk_enctypes=des_cbc-crc
dns_lookup_realm = false
dns_lookup_kdc = false

[realms]
AUTOMIC.COM = {
kdc = adserver.automic.com
admin_server = adserver.automic.com
kpasswd_server = adserver.automic.com
default_domain = AUTOMIC.COM
}

[domain_realm]
.kerberos.server = AUTOMIC.COM
.automic.com = AUTOMIC.COM
automic.com = AUTOMIC.COM

[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]

pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

3. In the sosite file, set the variable Java_mb to indicate the location of the files created in step 1 and 2. The
sosite file should then be sourced and the RMI server restarted.
 Applications Manager 9.4.1

The variable must start out with "2048m". In a UNIX sosite file this would be:

export Java_mb="2048m -Djava.security.auth.login.config=$AW_HOME/AM_GSSAPI.conf -

Djava.security.krb5.conf=$AW_HOME/krb5.conf"

If you are on a Windows or UNIX operating system with less memory available, substitute "2048m" with
"1024m".
4. Source in the sosite file by typing . sosite.
5. Start the Applications Manager processes by typing startso.
6. Launch Applications Manager client and the open the Automation Engine/Local Agent object and configure the
LDAP tab:

Field Do the following

Enable LDAP Make sure this box is checked.

URL To search for:

• Directories: Enter D.
• Users: Enter U.

Distinguished name (dn) If you would like to filter your user

base, enter a search string. Example:
CN=Users,DC=Automic,DC=com

Authentication mechanism GSSAPI

A sample LDAP tab for Active Directory is shown below.

 Applications Manager 9.4.1

7. Launch a new client session and log in with a valid account from GSSAPI directory to test the LDAP integration.

Enabling Applications Manager Auditing

Applications Managerincludes a robust auditing function. Applications Manager auditing monitors changes made
to several Applications Manager objects and their parts. You view audit information with Applications Manager
Report objects. Several Applications Manager Report objects ship with Applications Manager, they are named
AW_AUDIT_<object or object part>. For example, the AW_AUDIT_CHAIN Report shows auditing information
for Process Flows. These Reports reflect the original data, the change made, the date of the change, and the
Applications Manager User who made the change.
Enabling Audit for Applications Manager Objects
If you have the DBA User Group assigned to you, you will see an Audit tab on the Agents window for the
Automation Engine/Remote Agent as shown below.
 Applications Manager 9.4.1

From it you can turn on Applications Manager auditing. Applications Manager auditing allows you to see who has
edited objects. When auditing is turned on you should regularly schedule the PURGE_AUDIT_HISTORY Job
described below.
The Audit tab also includes fields that tell you when the first object was changed and the total number of objects
that have been changed. To break this information down by database table, click the Details button.
Auditing Backlog Changes
To audit Backlog changes, select the Enable auditing of backlog changes Automation Engine option. For more
information on setting Automation Engine options, see Setting Automation Engine Options.
Purging the Audit Tables
The PURGE_AUDIT_HISTORY Job purges the tables used for Applications Manager auditing. It includes a
single prompt where you specify how long you keep audit changes. This purges both object and Backlog audit
information. The default value is 60 days. If you are using Applications Manager auditing, you should set the
prompt value and create a schedule for this Job.

Specifying Email Settings for the Automation Engine

To send Notification emails, you must specify email sender information for the Applications Manager Automation
Engine/Local Agent to use. An example is shown below.
 Applications Manager 9.4.1

To specify email settings for the Automation Engine, select the Email tab of the Automation Engine/Local Agent
object and specify a host, open port, and sender. After defining the email settings, you can send a test email to the
sender by clicking the Test button.
DBA User Group Required
The Email tab is limited to Users who have the DBA User Group. If you do not have access to it, see your
Applications Manager administrator.
For information on creating Notifications, see the Development Guide.

Defining Agent Groups

To add an Agent Group, give the group a name and description. After creating Agents and Agent Groups, you can
assign Agents to the Agent Groups. You assign priorities and load factors for each Agent. If the Multi-Execution
option is selected, Jobs and Process Flows assigned to the Agent Group will run on every Agent in the Agent
Group. Agent Groups without the Multi-Execution option is selected are called regular Agent Groups.
When you submit a Job to an Agent Group, Applications Manager runs it on the first available machine in the
group. If the Multi-Execution option is selected, Jobs and Process Flows assigned to the Agent Group will run on
every Agent in the Agent Group. Agent Groups without the Multi-Execution option is selected are called regular
Agent Groups.
 Applications Manager 9.4.1

Applications Manager User Groups control access to Agent Groups. If you do not have access to them, see your
Applications Manager administrator.
Procedure
To create an Agent Group:
1. From the Agent Groups Selector window, click New.
Applications Manager opens the Select agent type window.
2. Select the Standard Agent Group type and click OK.
The Agent type you select determines which Agents can be included in the Agent Group. For information on
non-standard Agent types, see your related Applications Manager interface or extension documentation.
3. Enter a name and description for the Agent Group.
4. If you want to run the tasks assigned to this Agent Group on every listed Agent, select the Multi-Execution box.
When you run a Job, Process Flow, or Process Flow component through a multi-execution Agent Group,
Applications Manager automatically creates copies of the task and runs them on every Agent in the group. Each
task shows up in the Backlog so you can track execution.
5. Assign one or more Agents to the Agent Group.
You can assign Agent Groups to Jobs, the only Agent Groups you can assign to Process Flows are multi-execution
Agent Groups.
 Applications Manager 9.4.1

The APPWORX_AGENTS Agent Group

The APPWORX_AGENTS Agent Group is used by the SODELETE Job and should contain all the Applications
Manager Agents. SODELETE removes output files that have exceeded their retention days or the maximum
number of revisions. This ensures that SODELETE is executed on all Applications Manager Agents. SODELETE
is part of the SYSTEM Process Flow. For more information on SODELETE and the SYSTEM Process Flow, see
Managing System Records.
Next Step: Assigning Priorities and Load Factors
After adding Agents to an Agent Group, the next step is to assign a priority and load factor to each Agent in the
group. For more information, see Setting the Priorities and Load Factors for Agents in a Regular Agent Group.

Setting the Priorities and Load Factors for Agents in a Regular Agent Group
Load balancing with Agent Groups provides the means to dynamically balance the computing load among several
machines. The methodology used by Applications Manager provides the flexibility to manage load distribution to
suit the needs of almost any site.

Agent Group Terms

Priority: the priority of the Agent in comparison to the other Agents in the Agent Group you have defined.
Load factor: the capacity of the Agent in comparison to the other Agents in the Agent Group you have defined.
Procedure
To set an Agent's priority and load factor:
1. Select an assigned Agent from the Agent Groups window and click Edit.
Applications Manager opens a window where you can assign a new priority and load factor.
2. Enter the Agent's priority and/or load factor.
The lower the number you assign to an Agent in the Priority field, the higher priority it will have to run tasks.
The lower the number you assign to an Agent in the Factor field, the higher capacity it will have to run tasks.
For example, if Machine A has a capacity of 20 and Machine B has half the capacity of Machine A, you would
set Machine B's factor to 40.
Dynamic Load Balancing Algorithm
The algorithm to determine the Agent order is based on the following criteria:
• The priority of the Agent.
• The value of the Agent factor multiplied by the CPU utilization. If the Use Task Count Load Balancing vs. CPU
% option is checked, the Agent factor is multiplied by the count of tasks currently running on the Agent over the
maximum threads of the Agent).
• The last activity timestamp of the Agent.
Dynamic Load Balancing Examples
Example 1. You want to evenly distribute your workload over the three machines below.
To spread the workload over the three machines, set the priorities and factors the same.

Machine Priority Factor

A 50 50

B 50 50

C 50 50

Example 2. You want to evenly distribute your workload over the three machines below.
Machine A has twice the capacity of Machine B and Machine C. By setting the factors below, the workload will be
distributed based on the capacity of the machines.
 Applications Manager 9.4.1

Machine Priority Factor

A 50 20

B 50 40

C 50 40

Example 3. You want to evenly distribute the workload over two machines, and use a third machine as a backup
when the first two machines reach capacity.
Machine A and Machine B will carry the primary workload of the three machines. Machine A has three times more
capacity than Machine B. You use Machine C when Machine A and B reach capacity.

Machine Priority Factor

A 40 10

B 40 30

C 50 50

Example 4. All General Ledger tasks will run with Machine A as the primary machine, but use Machine B when
Machine A reaches capacity or is unavailable. All MRP tasks will run with Machine B and C as the primary
machines, but use Machine A for overflow. Machines A, B, and C have the same capacity.
In this case, we define two Agent Groups: One for General Ledger tasks and one for MRP tasks. Then all General
Ledger Jobs should be assigned to the GL Agent Group and all the MRP tasks assigned to the MRP Agent Group.
General Ledger Agent Group

Machine Priority Factor

A 40 50

B 50 50

MRP Agent Group

Machine Priority Factor

A 50 50

B 40 50

C 40 50

Managing System Records

The SYSTEM Process Flow is critical to the daily maintenance of Applications Manager. It contains two Jobs:
DELDEFAULT and HISTORY_PURGE. The Process Flow definition is shown below.
 Applications Manager 9.4.1

On a new install, the start time for the SYSTEM Process Flow is set to run at 00:00 (12:00 midnight). You may wish
to change this setting to a different time when processing is light.
Usually, you rely on the SYSTEM Process Flow to maintain history records and output files. However, if you want to
override the Process Flow, you can submit each Job on an ad hoc basis.
Deleting Output Files
When you define a Job, you can set the number of days the output will be retained by Applications Manager in the
Retention days setting on each Job's Output tab. When a Notification is assigned to the Job, it will use that Job's
retention days to determine when to delete the Notification's log files.
The SODELETE Job (alias DELDEFAULT) deletes the output files that have exceeded their retention settings.
The SODELETE Job also deletes log files created by Applications Manager processes. By default, they are deleted
after seven days. You can change this setting to a different number of days. To do so, add the following line under
[default] in the awenv.ini file located in the site directory as shown below:

LOG_RETENTION_DAYS=3

The example above will delete log files older than three days. This setting only applies to log files that are created
after you add the line to the awenv.ini file. Also, the LOG_RETENTION_DAYS setting doesn't change retention
days for output files, which is controlled by the Retention days setting on each Job's Output tab.
SODELETE also deletes in any files in the tmp directory that are older than seven days.
The SODELETE Job does not run a script like most Jobs, Applications Manager executes Java every time it runs.
Therefore you should not copy this Job and edit its script.
Deleting History Records
 Applications Manager 9.4.1

The HISTORY_PURGE Job deletes all history records that are older than the number of days you specify in the
Job's prompt. The default is 60 days.
To satisfy Success since last run predecessor links, there must be a reference to the predecessor task in the
database. These references are removed by running the HISTORY_PURGE Job. In most cases this would never
be a concern because History is saved for many more days than a predecessor would need to check for. If a
situation like this occurs, use conditions instead of Success since last run predecessors.

Creating Reports and Browsing the Database

Applications Manager comes with a set of predefined Reports that tell you information about your Applications
Manager objects. You can also import an extensive set of Applications Manager History Analysis Reports that you
can use to review how tasks were processed through Applications Manager. You can create custom Reports from
the Reports window.
Viewing Reports
You can open Reports from the object type selector windows and from several of the operations windows. A
sample Report is shown below.

Creating Reports
Applications Manager Reports are based on SQL statements. To create a Report, you either start with an existing
SQL statement and customize it, or create a Report from scratch. You can add database tables and views to a
Report. Once database tables and views are added to a Report, you can add columns from them. Each column can
be customized in the Report. The object definition for the Report above is shown below. For more information on
creating Reports, see Steps for Creating Reports.
 Applications Manager 9.4.1

Creating Jobs from Reports

You may want to create Applications Manager Jobs to run your Reports. With Jobs, you can schedule your
Reports, and add them to Process Flows. For more information, see Creating Jobs from Reports.
Retrieving Historical Data for Applications Manager Historical Analysis Reports
Applications Manager ships with several pre-defined Reports that analyze your task history. These Reports are
referred to as Applications Manager History Analysis or AHA Reports. They include an AHA prefix designation in
their names. For example, the AHA-FINISHED_JOBS_BY_STATUS_HR Report returns completed tasks according
to status by hour. Data relating to AHA Reports is generated and loaded into Applications Manager by running the
CALC_HISTORY_STATISTICS Job. For more information, see Retrieving Historical Data for Applications Manager
Historical Analysis Reports.
Browsing the Applications Manager Database
 Applications Manager 9.4.1

You can browse database tables, views, triggers, and procedures in the Applications Manager database by
selecting Applications Manager DB Browser from the Tools menu of the Applications Manager desktop. For
more information, see Browsing the Applications Manager Database.

Steps for Creating Reports

Applications Manager Reports are based on SQL statements. When creating a Report, you select tables and
views, and select columns from them. To create a Report, you either start with an existing SQL statement and
customize it, or create a Report from scratch. A sample Report object is shown below.

To create a Report:
1. From the Reports Selector window, click New.
Applications Manager opens the Reports window.
2. Enter a name and title for the Report.
 Applications Manager 9.4.1

The title will be displayed in the title bar of the Report's window when it is run.
You can enter &<column number> in the title to display the current value from that column when viewing the
Report.
3. Select a Report type to determine the window where the Report can be viewed from by default. For example, if
the Report you are defining makes the most sense to be opened while defining Jobs, you would select the Jobs
type.
4. Specify the database for the Report by doing one of the following:
• If the Report will be run against the Applications Manager database, leave 'No Selection' as the value of the
Login field. This will use the Oracle Database Login used to connect to the Applications Manager database.
• If the Report will not be run against the Applications Manager database, select the Login for the database
you wish to run the SQL statement against.
To evaluate dynamic Substitution Variables, Data Types, or Reports on a database other than the
Applications Manager database, the Login object must be defined for JDBC use. For more information, see
Specifying JDBC Requirements for Logins.
5. Specify the SQL for the Report by doing one of the following:
• If you are starting with an existing SQL statement, cut and paste or type the SQL statement in the SQL
box. Even if you are creating a Report with existing SQL, you will need to add the columns using the Select
Columns window as described in the next step. For an example, see Example: Creating a Report from
Existing SQL.
• If you are creating the Report from scratch, select tables/views for the Report. For more information, see
Selecting Tables and Views.
6. Click New to open the Select Columns window (not shown in this topic). From the Select Columns window, do
one or both of the following and click OK:
• Assign columns by moving them from the Unassigned to the Assigned boxes.
• Add any columns specified in the SQL box on the Report window to the Report.
For more information on the Select Columns window, see Adding Report Columns.
7. Customize the Reports by editing the Report columns. This includes adding prompts to Reports. For more
information, see Editing Report Columns.
8. Join/order columns as necessary by entering the appropriate code in the SSQL statement. Note you cannot
order the columns from the GUI. If the Report was created by entering a SQL statement, this step may have
already been done. This requires a knowledge of SQL.

Selecting Tables and Views

You can add database tables or views to the SQL for a Report by clicking the Select button on the Reports
window. This opens the Select Tables/Views window shown below.
 Applications Manager 9.4.1

Select one or more tables and/or views from the Select Tables/Views window. To make multiple contiguous
selections, hold down the Shift key and click the first and last values. To make multiple nonadjacent selections, hold
down the Control key and click on the values. To show tables for all database users, click the Show All Tables/
Views box.
Use the Search field to quickly find objects. The Search field accepts valid UNIX regular expressions. In the image
above, %LIB is entered in the Search field to quickly find the SO_LIBRARIES view.
If you use multiple tables or view names in your Report, you should use pseudonyms to differentiate which table
each column belongs to. To add a pseudonym to the tables/view names, add a single character to the Pseudonym
field. You can use the pseudonym as an alias for the table or view in your SQL statement.
When you have selected your tables and/or views, click OK. Applications Manager adds the tables and/or views to
the SQL box on the Reports window. In the image below, the SO_LIBRARIES table is added to the SQL box.
 Applications Manager 9.4.1

Using Applications Manager Modeling and Audit Views

Applications Manager comes with a set of predefined modeling and audit views. With them, you don't need an
extensive knowledge of the Applications Manager database table structure. Their columns closely match the field
names used in the Applications Manager client.
Modeling view names start with an AM_. For example, AM_DATA_TYPES and AM_NOTIFICATIONS.
Audit view names start with AUDIT_. For example, AUDIT_AGENTS and AUDIT_USERS.
For an example Report that uses an Applications Manager modeling view, see Example: Finding Components by
Alias Name.
 Applications Manager 9.4.1

Adding Report Columns

Once you add one or tables/views to a Report, you can add columns to a Report by clicking the New button on the
Reports window. This opens the Select Columns window shown below.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Select one or more columns from the Select Columns window. To write the columns in <table name>.<column
name> format, click the Use Table Names box.
If you defined pseudonyms for your tables/views, the pseudonym names will be displayed in the
Unassigned/Assigned boxes for each column name. Pseudonyms allow you to differentiate between columns in
different tables/views with the same name.
When you add columns to a Report, they are displayed in the Columns box on the Reports window shown below.
For information on editing columns, see Editing Report Columns.

Editing Report Columns

To edit fields for a column, select the entry for the column and click Edit.
Applications Manager 9.4.1
 Applications Manager 9.4.1

The fields are described below.

• Field
The database field.
• Heading
The text that will be displayed in the Report heading for this column.
• Width
The column character width. If no value is specified, the column width will be determined by the column's
longest entry.
• No Print
The Report does not show this column in the Report when this box is checked. It does put the column in the
select part of the SQL statement. This is generally used for order bys or group bys.
• Break
Inserts a break when the value in this column changes.
• Don't Skip: Breaks a line between each row.
• Skip Line: Breaks and skips a line between each row.
• Skip Page: Breaks and skips a page between each row.
• Prompt
Used to pass a prompt value into the SQL statement.
• SQL
Passes the prompt information as a where clause, and includes it as a column in the output.
• No SQL
Passes the prompt information as a where clause, but does not include it as a column in the output. It doesn't
put the field in the Select part of the SQL statement. This is used for prompts which are not part of the Report
but are used in the where by.
• Replace
Replaces &<column name> with the value of the prompt, where <column name> is the name value in the
Field box above.
• Data Type
Defines the type of data validations that will be used for the prompt values. For more information on Data Types,
see the Development Guide.
• Default Value
The default prompt value is displayed in the Value column. You can use Substitution Variables in this field.
If your prompt values include spaces or special characters, such as & or %, enclose those values in double
quotes.
• To Date
An end date used with the Dates data type.
• Upper Case
When selected, text entered for the prompt will be forced to upper case.
• Required
When selected, the prompt must have either a default value or User value entered in the Value column.
• Multi-Select
Some Data Types include SQL statements that allow you to select prompt values from a list. This checkbox
allows Users to select one or more values.
• Justify
Align text to the default setting, or to the left or right margins.
• Wrap
Determines what happens when text is longer than the column width.
• Truncate: Displays only the selected width of text.
• Wrap: Wraps the characters in the field regardless of word breaks.
• Word Wrap: Wraps based on the whole words in the field.
 Applications Manager 9.4.1

This field will only be active if a value is entered in the Width field.

Example: Creating a Report from Existing SQL

Create Reports by adding or building SQL statements and selecting columns from tables or views. In this example,
a SQL statement is entered for a Report. The Report will return a list of Jobs and give some details about them.

Specifying a Name, Title, Type, and Login

A name and title is entered for the Report. Jobs is selected in the Type field because this Report will usually be
viewed from the Jobs Selector window. Since this Report will be run against the Applications Manager database, a
Login does not need to be selected from the Login field.
Entering a SQL Statement in the SQL Box
 Applications Manager 9.4.1

In this example a SQL statement already exists, and has been cut and pasted into the SQL field. By creating an
Applications Manager Report object for it, users can run the Report from the Applications Manager client. The SQL
statement for the JOB_INFO Report shown in the example above is only partially visible. The entire SQL statement
is shown below:

select m.so_application application,

m.so_module module,
m.so_job_descr description,
m.so_program command,
cp.so_commd_type command_type,
ap.so_appl_path || cp.so_command_path ApplicationPath
from so_job_table m, so_command_paths cp, so_applications ap
where m.so_command_type = cp.so_commd_type(+)
and m.so_application = ap.so_appl(+)
order by m.so_application;

Adding Columns to a Report

Even though the SQL statement entered in the SQL box is complete, its columns have to be added to the Report
object. To add columns to the Report, click the New button on the Reports window. Applications Manager opens
the Select Columns window shown below.
 Applications Manager 9.4.1

When you originally create a new Report from an existing SQL statement, Applications Manager displays the select
portion of the SQL statement in the Fields box.
Warning: If you close this window by clicking either the X in the title bar or the Cancel button, any
information in the Fields box will be lost from this window and from the SQL box on the Reports window.

All available fields from the SQL statement are displayed in the Unassigned column. If you wish to assign any of
these columns to the Report, you may do so now or later. The only fields added for this example are the fields in
the Fields box.
To close the Select Columns window, click OK.
Applications Manager closes the Select Columns window, and lists each column from the Fields and Assigned
boxes in the Columns table on the Reports window.
 Applications Manager 9.4.1

The Report will be available on the selector window for the object type or operations window you selected in the
Type field. To show the Report from this window, click the Show button. For more information on viewing Reports,
see the Development Guide.

Example: Adding a Prompt to a Report

When the Report shown below is run, it returns a page with all the employees for each department sorted by
department name.
Applications Manager 9.4.1
 Applications Manager 9.4.1

The SQL used to generate the Report is shown below:

select emp.ename,dept.dname
from emp, dept
where emp.deptno = dept.deptno
order by 2

You can view the SQL used to generate a Report by clicking the Show SQL button.
By adding a prompt to the column that selects a department, you can have the Report list only the employees in a
single department. To accommodate the prompt, the SQL is modified as shown below:

select emp.ename,dept.dname
from emp, dept
where emp.deptno = dept.deptno AND dept.dname
='SALES'
order by 2

In the image below, the Prompt box is checked and the Dept_Name data type is selected. The Dept_Name data
type uses the following SQL statement to allow users to select a department name from the DEPT table:

select dname, to_char(deptno) from DEPT

Applications Manager 9.4.1
 Applications Manager 9.4.1

When a user runs the Report now, they are prompted to select a department as shown below.

The output for the Report now lists only the employees in the selected department as shown below.
 Applications Manager 9.4.1

The SQL used to generate the Report above is shown below:

select emp.ename,dept.dname
from emp, dept
where emp.deptno = dept.deptno AND dept.dname
='SALES'
order by 2

Example: Using Prompted NO_SQL Columns

You can add pseudo columns to Reports by editing the column and checking No Sql when editing a column.
Pseudo columns do not print but their values can be used in the whereby.
 Applications Manager 9.4.1

This should only be done with no_sql columns or columns which are defined as page break columns.
When the SQL is executed, its value will only be used in the statement's whereby statement substituting its value.
The column was:

& *next_extent > c.tb_bytes

When substituted it becomes:

AND 2 *next_extent > c.tb_bytes

 Applications Manager 9.4.1

where the '&' is replaced by 'AND 2'.

SQL Statement for the Report
The SQL used to generate the Report is shown below:

select
SEGMENT_TYPE,SEGMENT_NAME,a.TABLESPACE_NAME,to_char(BYTES,'999,999,999,999'),
to_char( NEXT_EXTENT,'999,999,999,999'),to_char(c.tb_bytes,'999,999,999,999'),EXTENTS,MAX_EXTENTS,
from user_segments a,( select b.tablespace_name,sum(bytes) tb_bytes
from user_free_space b
group by b.tablespace_name) c
where c.tablespace_name = a.tablespace_name
AND a.TABLESPACE_NAME='USERS'
AND 2 *next_extent > c.tb_bytes

order by 1,2

Example: Finding Components by Alias Name

This example shows a simple Report you can create using an Applications Manager modeling view. If you want to
know where a Job is referenced in Process Flows, you can go to the Jobs Selector window, select the Job and
click Usage. But you might want slightly different information than that. You may want to know where the Job is
assigned as a Process Flow component under a particular alias name. Or perhaps you know that an alias name is
used for a component in one of your Process Flows, but you don't remember which one. For cases like this, you
can create a Report to easily find the information you are looking for.
Applications Manager 9.4.1
 Applications Manager 9.4.1

Creating an Alias Usage Report

This example shows how to create a sample alias Report that allows you to enter an alias name as a prompt value
to return a list of Process Flows that include that alias. You can follow these instructions to create this Report, or
alter them slightly to create your own version. To create this Report:
1. Start by giving the Report a name, title and type as shown below. You won't need to select a Login because you
are logging into the Applications Manager database.
Applications Manager 9.4.1
 Applications Manager 9.4.1

2. Click the Select button to open the Select Tables/Views window.

3. Enter 'AM' in the Search field to view a list of the Applications Manager modeling views.
With the Applications Manager modeling views you don't need an extensive knowledge of the Applications
Manager database table structure. Their columns closely match the field names used in the Applications
Manager client.
4. Select the AW_CHAIN_COMPONENTS view and click OK.
5. Click New on the Reports window to add columns.
6. On the Select Columns window select the CHAIN_NAME, COMPONENT_NAME, and
COMPONENT_MODULE columns as shown below.
 Applications Manager 9.4.1

7. To prompt for an alias name, edit the COMPONENT_NAME column as shown in the example above. In the
example above, the following edits were set:
• The text in the Description field was edited to make a better prompt description.
• The Prompt box was checked.
• Character was selected in the Data Type field.
 Applications Manager 9.4.1

8. You can now test the Report by clicking the Show button on the Jobs window.
In the image below, DELDEFAULT is entered as the prompt value. DELDEFAULT is an alias name for the
SODELETE Job when used in the SYSTEM Process Flow that ships with Applications Manager.

Output from the Report is shown below.

Showing Reports and Their SQL from the Reports Window

You can show Report data from the Reports window. While viewing Report data in this way, you can view the SQL
statement used to create it.
To view Report data from the Reports window shown below, click the Show button.
 Applications Manager 9.4.1

Some Reports require you to enter prompt values. If the Report you select requires prompt values, you must
respond to them in the Report Parameters window shown below. Once prompts are provided (if necessary),
Applications Manager displays the Report.
 Applications Manager 9.4.1

Changing the Lines per Page

You can specify the number of lines displayed on each page using the Lines per Page field. The new setting will
go into effect when you click the Reformat button. Doing so will update the time and date in the Report header. It
will not recompile the SQL.
Showing Report SQL
To show the SQL statement used to display a Report object, click the Show SQL button in the Report window as
shown below.
You can only show SQL for a Report when viewing Report data from the Report object's definition. The Show SQL
button is not available when viewing Reports from operations or selector windows.
 Applications Manager 9.4.1

How Task History Report Data Is Generated

Data relating to task history used in Reports is generated and loaded into Applications Manager by running the
CALC_HISTORY_STATISTICS Job. If a task history Report data does not seem current, it could be because this
Job has not recently run. For more information, see Retrieving Historical Data for Applications Manager Historical
Analysis Reports.

Creating Jobs from Reports

Youmay want to create Applications Manager Jobs to run your Reports. With Jobs, you can schedule your Reports,
and add them to Process Flows. To create Jobs for one or more Reports, highlight the Reports in the Reports
Selector window and click Jobs. In the image below, the AHA-APPL_JOBS_FINISHED_BY_DAY Report is
selected.
 Applications Manager 9.4.1

Applications Manager opens the Create Jobs window and lists the Jobs selected. You cannot change the Job's
name when creating it. If you don't like the name, you can copy the Job to a new name and delete the original. To
add the Job(s), click OK. Applications Manager creates the new Jobs. Jobs created from Reports will have the
AW_REPORTS Application assigned to them as shown below.
 Applications Manager 9.4.1

Editing Report Jobs

You can edit the Report Jobs like any other Applications Manager Job. If you wish, you can fill in the non-required
fields on the General and other tabs of the Jobs window.
A Job for the AHA-APPL_JOBS_FINISHED_BY_DAY Report is shown above. The information in the Program box
is read-only.
Database Login Not Needed
When you generate a Job from an Applications Manager Report, you do not need to specify a Database Login in
the Job. The Job will use the Login specified in the Report definition.
Report Job Prompts
When Jobs are created from Reports, they include:
• An 'Export Format' prompt: You use this prompt to determine whether to separate entries in a row by spaces,
commas, or tabs. It is useful if you will be exporting the Report to another Application.
• A 'Lines Per Page' prompt.
• All prompts defined for the Report.
Prompts for a Report Job are shown below.
 Applications Manager 9.4.1

Retrieving Historical Data for Applications Manager Historical Analysis Reports

Applications Manager History Analysis or AHA Reports include an AHA prefix designation in their names. For
example, the AHA-FINISHED_JOBS_BY_STATUS_HR Report returns completed tasks according to status by
hour.
AHA Report data is compiled by running the CALC_HISTORY_STATISTICS Job. Depending on the amount of data
in your History, it may take a long time to execute. The CALC_HISTORY_STATISTICS Job can be requested and
submitted on an ad hoc basis. However, we suggest you create a schedule to run it daily during off hours, or as
often as necessary.
 Applications Manager 9.4.1

The CALC_HISTORY_STATISTICS Job includes prompts to specify start and end dates.
Running CALC_HISTORY_STATISTICS for the First Time After an Upgrade
If you have upgraded from a previous version of Applications Manager that did not include the
CALC_HISTORY_STATISTICS Job, it could take a long time to complete the first time it runs.
The first time you run CALC_HISTORY_STATISTICS without prompt values specified, it evaluates History starting
with its oldest record and runs the calculation up to the current day. This is can take a long time to run, depending
on how much History you have.
After that, every time you run CALC_HISTORY_STATISTICS without prompts specified, it starts its calculation from
the most recent date it finds in the aw_reports_history database table.
Importing the CALC_HISTORY_STATISTICS Job and AHA Reports
To bring the CALC_HISTORY_STATISTICS Job and AHA Reports into Applications Manager, You must run an
Applications Manager import by doing the following:
1. Select Import from the Activities menu on the Applications Manager desktop to open the Import window.
2. From the File menu on the Import window, choose Open Import File.
Applications Manager displays the Import Files window.
3. Choose import file AppWorx_History_Stats from the list and click OK.
A list of mappable objects appears in the Import window. You should not have to re-map any of these objects.
 Applications Manager 9.4.1

4. To start the import, click Import.

5. Open the Explorer window and check that the IMPORT task is running. It will return a FINISHED status when
complete.
The Automation Engine and Agent must be running for the IMPORT task to run.
For more information on running imports, see the Development Guide.

Browsing the Applications Manager Database

You can browse database tables, views, triggers, procedures and sequences in the Applications Manager database
by selecting Applications Manager DB Browser from the Tools menu of the Applications Manager desktop.
Applications Manager opens the Applications Manager Database Browser window shown below.

The Applications Manager Database Browser window is limited to Users who have the DBA User Group. If you
do not have access to it, see your Applications Manager administrator.
Selecting a tab on the left side of the screen will bring up different sub-tabs on the right side of the screen.
By default, the database browser Login is configured for the Applications Manager database defined during
installation. If you move the Applications Manager database, you will need to reconfigure the Login. To reconfigure
your database Login, select Change Database Login from the Login menu.
Searching for Table Data
Use the Data tab on the right side of the screen when the Table tab is selected to view table data. The Tables and
Data tabs are selected below.
 Applications Manager 9.4.1

By default the Data tab lists the first 100 rows of data in a table. Use the features described below to find rows:

To: Do the following:

Search for a table Enter text in the Search field on the Table tab on the
left side of the screen. You can type the first few letters
of a table's name in the Search field, and Applications
Manager will find it. The Search field accepts valid
UNIX regular expressions.

Refresh the list of tables Click the Refresh button on the left side of the screen.

To query data with a where statement Enter a Where statement in the field on the right side
of the screen and click Query. Applications Manager
will return a list of the first 100 rows using the Where
statement.

View the next 100 rows Click the Next Fetch button to fetch the next hundred
rows. Applications Manager will add these rows to the
current list.

Running Selects from the Database Browser

To run select statements from the database browser, pick Run Select from the Select menu as shown below to
open the Run Select Statements window. On the Run Select Statements window, enter a select statement and
click Run.
 Applications Manager 9.4.1

Parsing Oracle Errors in Triggers from the Database Browser

To parse Oracle errors in triggers from the database browser, pick Parse Oracle Errors from the Help menu as
shown below to open the Parse Oracle Errors window. On the Parse Oracle Errors window, enter an Oracle error
and click Parse. Applications Manager displays tabs for the corresponding triggers at the bottom of the window.
The actual lines where the text is found are highlighted.
 Applications Manager 9.4.1

Event Logging
Applications Manager can log status changes for tasks, Agents, and the Automation Engine.
Many companies use tools such as HP OpenView, SNMP, Patrol, Tivoli, and Unicenter to continually monitor all
operations activities. Applications Manager can log status changes for tasks, Agents, and the Automation Engine.
 Applications Manager 9.4.1

You can use a monitoring tool to query the output files and report Applications Manager statuses. Sample output
from an event log for tasks, Agents, and the Automation Engine is shown below.

Master IP Master TimeStamp Status Keyword/Module Agent/Jobid

300.1.1.74 PROD 2006071413:55:37 ABORTED FIN_1 13285
300.1.1.74 PROD 2006071413:59:36 ABORTED FIN_3 13290
300.1.1.74 PROD 2006071414:00:03 KILLED FIN_3 13290.01
200.1.1.47 PROD 2006071414:23:52 Stopped agent PROD

Logging Task and/or Agent and Automation Engine Statuses

You can log status changes for:
• Tasks
• Agents and the Automation Engine
• Both
You select the statuses you wish to log and set options such as file naming and retention. For more information,
see topics Logging Task Events and Logging Agent Events.
Formatting Event Logs
You format the event logs to determine which columns to include and how to present their data. For more
information, see Formatting Task and Agent Event Files.

Logging Task Events

Applications Manager can log status changes for tasks, Agents, and the Automation Engine. You configure task
status logging options from the Task Events tab of the Settings window. To open the Settings window, select
Settings from the Options menu. Directions for creating Agent status logs are included in Logging Agent Events.
 Applications Manager 9.4.1

The Task Events and Agent Events tabs on the Setting window are limited to Users who have the DBA User
Group. If you do not have access to it, see your Applications Manager administrator.
The Task Event settings are described below.
• Task event file
The path and file name of the log file you want to write to.
• Maximum file bytes
The number of bytes before the file gets copied to a different name and a new file gets created using the current
task event file name. The copied file will be named the same as the original task event file with a number
appended to it. If no file named <file name>1.log exists, it will be copied to that name. If <file name>1.log
exists, Applications Manager will increment the number by one until a file name does not exist. Otherwise it will
replace the oldest file.
• File retention days
The number of days before the task event file will be deleted.
• Maximum number of files
The number of event files to keep. This includes the current task event file and all copied files.
• Task event logging on
The name says it all, if this box isn't checked, you aren't logging task events.
 Applications Manager 9.4.1

• Write column headers

Writes headers in the event log for the selected columns.
• Write on/off messages
Writes a message to the task event log when task event logging is turned off or on.
To move statuses between the Unassigned and Assigned columns, double-click or use the arrow keys.
Some intermittent statuses will be available for logging.
Formatting Event Files
You format the task event log file by selecting Task Event Log under Tables from the Options menu. For more
information, see Formatting Task and Agent Event Files.

Logging Agent Events

You configure Automation Engine and Agent status logging options from the Agent Events tab of the Settings
window. To open the Settings window, select Settings from the Options menu. Directions for creating task status
logs are included in Logging Task Events.
 Applications Manager 9.4.1

The Task Events and Agent Events tabs on the Setting window are limited to Users who have the DBA User
Group. If you do not have access to it, see your Applications Manager administrator.
The Agent Event settings are described below.
• Agent event file
The path and file name of the log file you want to write to. If the Write to task event file option is selected, this
and the following three settings will be grayed out.
• Maximum file bytes
The number of bytes before the file gets copied to a different name and a new file gets created using the
current event file name. The copied file will be named the same as the original task event file with a number
appended to it. If no file named <file name>1.log exists, it will be copied to that name. If <file name>1.log
exists, Applications Manager will increment the number by one until a file name does not exist.
• File retention days
The number of days before the event file will be deleted.
• Maximum number of files
The number of event files to keep. This includes the current event file and all copied files.
• Write to task event file
When checked, all control of where and how the Agent events are logged is switched to the Task Events tab's
settings and therefore requires task event logging to be enabled in order to track Agent events.
• Task event logging on
The name says it all, if this box isn't checked, you aren't logging Automation Engine and Agent events.
• Write column headers
Writes headers in the event log for the selected columns.
• Write on/off messages
Writes a message to the event log when Agent event logging is turned off or on.
To move statuses between the Unassigned and Assigned columns, double-click or use the arrow keys.
Warning: In order to log the CPU WAIT status, you must also assign the RUNNING status.

Some intermittent statuses will be available for logging.

Formatting Event Files
You format the Agent event log file by selecting Agent Event Log under Tables from the Options menu. For more
information, see Formatting Task and Agent Event Files.

Formatting Task and Agent Event Files

You format the task or Agent event log files by selecting Agent Event Log or Task Event Log under Tables from
the Options menu.
To edit the format of a task or Agent event file, open the Options menu, select Tables, then select either Task
Event Log or Agent Event Log. The Setup window for task event logs is shown below.
 Applications Manager 9.4.1

The top of the window shows an example log file. The bottom of the window displays a list of the columns that can
be displayed.
Making Changes
The table below describes how to customize Applications Manager tables.

To: Do this:

Display a column Check the VISIBLE column.

All visible columns are brought to the top of the list.
Newly checked columns are added to the far right side
of the table. You can click the title of the column in the
top display and drag it to a new location.

Change the name of a column Edit the entry in the Name column.

Control the width of a column Enter a number of characters in the WIDTH column.

Format date columns Select a date format from the FORMAT column.

Change the order of the columns Select the title of a column in the top window and drag it
to a new location.

Return the table to its last saved setting Click the Reset button at the bottom of the window.
 Applications Manager 9.4.1

Applications Manager Processes

All Applications Manager Agents are now multi-threaded Java Agents. There are no longer C Agents. The
AgentService process runs on all Agents. The awcomm process runs only on the Automation Engine machine.
Normally an additional process called RmiServer is also run on the Automation Engine machine.
There is only one network connection between an Agent and the RMI server and that connection is always initiated
by the AgentService process. This connection supports two way communications. That is to say the RMI server
can communicate with the remote AgentService over the same port. This also functions as automatic Agent
failover in the event of the Automation Engine's RMI server failing.
To ensure secure communications between the Automation Engine and the various processes, all messages are
encrypted.
To see the status of the Applications Manager process, issue an awexe node command.
This chapter complements chapter How a Task Runs. That chapter focuses on Job execution from a higher, more
general level. It does not address specific processes. This chapter is more technical, focusing on the processes
active at each step.
The WatchWorx Process
When started, the WatchWorx process monitors all other Applications Manager processes on an Agent or
Automation Engine and attempts to restart them if they go down. For more information, see The watchworx
Process.
The awcomm Process
The awcomm process provides a port directory service for the Automation Engine machine. It stores the name
of each Automation Engine and its listening port, and makes it available to AgentService processes. There is
no awcomm on Remote Agent machines and there is usually one awcomm process on an Automation Engine
machine. For more information on the awcomm process, see The awcomm Process.
The AgentService Process
The AgentService process establishes a unique port. The port communicates with the RmiServer processe(s).
If the port numbers are not specified in the awenv.ini file, Applications Manager will determine the first available
port between 49152 and 65535. AgentService performs required Agent functions to launch, manage, and monitor
tasks as instructed by the Automation Engine. AgentService also services requests to view local output.
The AgentService process for the Automation Engine's Local Agent connects directly to the database, but the
AgentService processes for Remote Agents connect to the Automation Engine's RmiServer process.
The AgentService process functions as automatic Agent failover in the event of the Automation Engine's RMI
server failing provided an additional RmiServer process is online.
The AgentService process replaces the Automation Engine/Remote Agent stack, awapi, awagent, and awoae
processes from when previous Applications Manager versions were named AppWorx. The awapi process's
function is included in the AgentService JVM and it no longer listens on a port. The only way to communicate with
it is though a pipe file. For more information on the AgentService process, see The AgentService Process.
Automation Engine/RmiServer Process
The RMI server for the Applications Manager Automation Engine is responsible for initiating and monitoring task
execution. Because the Automation Engine is incorporated with the RMI server, there is no separate Automation
Engine process.
The Automation Engine monitors the Applications Manager task Queue and Job/Process Flow schedules and
determines when scheduled tasks are eligible for execution. When a task is eligible for execution, the Automation
Engine collects the necessary information from the database. Then the Automation Engine requests that the
Agent's AgentService process create the pr and pm program execution files and launches the pm script. After the
task has been launched, the AgentService process monitors the task until it goes to completion.
The RMI Server process serves out information to the Applications Manager Java client. It gets its Oracle SQL*Net
connect information from the awenv.ini file in the site directory, and decrypts its login information from the
Masters.properties file. For more information on the RmiServer process, see The RmiServer Process.
Program Execution Processes
The program execution processes include awexe and awrun. Program execution processes run only when
executed, whereas the other processes are persistent.
 Applications Manager 9.4.1

The awexe process allows you to issue various Applications Manager functions from the operating system
command line or from scripts. Functions can include such things as updating Substitution Variables values,
retrieving values from multi-select prompts, and taking actions on tasks in the Backlog.
The previous awprint is replaced by "awexe awprint line="xxxxxxxxx":

> awexe awprint

PRINTSIZE -n filename -j jobid -s size
PRINTONLY -u user_log_seq -c copies -p printer -r requestor -t printerText
PRINT -j jobid -n filename -c copies -f outputFunction -d outputDirectory -b sourceDirectory -o agent -r
requestor -p printer -t printerText -v viewName -k retentionDays

The awrun process allows you to submit tasks from the command line or in scripts.
Program execution processes are discussed further in Task and Program Execution.

Starting and Stopping Automation Engine and Agent Processes

The startso and stopso commands are used to start and stop Applications Manager processes in UNIX and
Windows. In Windows, you can also start and stop processes from the Windows Start menu. You can issue the
startso and stopso commands by themselves or with parameters. Before starting or stopping processes, you must
set the environment. You can issue these commands on Automation Engine or Agent machines. When you issue
the start or stop commands, they start or stop the processes in the order they are listed below.
Setting the Environment
Before starting or stopping processes, you must set the correct environment by doing the following:
1. Go to the $AW_HOME/site directory (%AW_HOME%\site for Windows).
2. For UNIX, issue the following command:

. sosite

If you get an sosite not found error, try this command:

. ./sosite

For Windows, issue the following command:

sosite

After issuing the command, you should be returned to the command prompt.
Starting and Stopping Processes with startso and stopso
When issued with no parameters, the startso command starts:
1. awcomm
2. AgentService
3. RmiServer
The stopso command stops only the AgentService process.
Starting Processes, but not Backlog Tasks
 Applications Manager 9.4.1

If you are starting Applications Manager as part of a boot sequence, you may want to start Applications Manager
processes, but not allow the Automation Engine to execute tasks until you have had a chance to view the contents
of the Backlog. You can set this up with the following series of commands.

startso
stopso master

In this series of commands, the startso command starts the awcomm, AgentService, and RmiServer processes
on the Automation Engine (the Automation Engine will go into a Stopped status).
The stopso master command doesn't stop any actual processes, because those elements are performed on
threads of the RmiServer process.
Starting and Stopping Processes Individually when Troubleshooting
To start processes individually when troubleshooting, issue the start commands in the following order.

Command: Will start the following processes:

startso awcomm awcomm

startso agentservice AgentService and awapi

startso rmi RmiServer

The corresponding stop commands can be issued in the reverse order to stop the processes individually.
Overriding Process Startup Wait Times
If processes don't startup within their default times the start process is aborted. You can override the wait times by
adding entries in awenv.ini file located in the site directory for the Automation Engine or an Agent. The defaults
values are:

AgentWait=60
AgentScan=60
RmiWait=60
RmiScan=60
Awcomm_wait=10

The values of the AgentScan and RmiScan variables are the numbers of seconds after which the log is scanned
for a successful start. AgentScan should be set to the same value as AgentWait and RmiScan should be set to
the same value as RmiWait. For example if you set RmiWait to 90, you should also set RmiScan to 90.
Stopping Processes Immediately
If necessary, you can eliminate the default 30 second wait for processes to stop after issuing a stop command them
by issuing the stopso -now <process name> command. For example:

stopso -now awapi

Warning: This is not recommended in normal situations.

Parameters for startso and stopso

It is generally recommended that you start and stop processes with the basic startso and stopso commands,
or if monitoring processes with WatchWorx, with the startso watchworx and stopso watchworx commands.
Additional parameters that can be used with the startso and stopso commands are described in the following
 Applications Manager 9.4.1

table. Parameters are passed in the format <command> <parameter>. For example, to pass the rmi parameter to
the startso command, you would enter:

>startso rmi

The table below describes which processes the startso and stopso commands start and stop when passed with
parameters.

Parameter Starts Stops

<Agent name> The startso <Agent name> The stopso <Agent name>
command starts the following command doesn't stop any actual
-or-
processes for a local or Remote processes, but it does put the Agent
agent <Agent name> Agent where <Agent name> is the into a Stopped status and stop
name of the Agent: the Agent from processing newly
submitted tasks.
• awcomm
• AgentService (which starts
awapi)
It also enables the specified Agent to
start if stopped previously.

agent • awcomm The stopso agent command doesn't

• AgentService stop any actual processes, but it
• awapi does put the Agent into a Stopped
status and stop the Agent from
It also enables the local Applications processing newly submitted tasks.
Manager Agent to start if stopped
previously.

agent local The startso agent local or startso The stopso agent local or stopso
agents commands start the agents commands don't stop any
-or-
following processes for all Local actual processes, but it does put
agents Agents: the Agent(s) into a Stopped status
and stop the Agent from processing
• awcomm
newly submitted tasks.
• AgentService
• awapi
They also enables the local
Applications Manager Agent(s) to
start if stopped previously.

agent all For all Agents assigned to the The stopso agent all command
Automation Engine: doesn't stop any actual processes,
but it does put the Agents into a
• awcomm
Stopped status and stop the Agent
• AgentService from processing newly submitted
• awapi tasks.
It also enables the local Applications
Manager Agent to start if stopped
previously.

agentservice • awcomm • AgentService

-or- • AgentService (which starts • awapi
awapi)
stack • awapi
 Applications Manager 9.4.1

Parameter Starts Stops

all • awcomm • AgentService (which stops

• AgentService (which starts awapi)
awapi) • RmiServer (if issued on the
• RmiServer (if issued on the Automation Engine)
Automation Engine) • The local watchworx process

awapi • awcomm • awapi

• AgentService (which starts
awapi)
• awapi

awcomm • awcomm • awcomm

• AgentService
• awapi
Warning: It is not
recommended to stop
the awcomm process,
especially if there are
multiple Automation Engines
or Agents installed on the
same machine.

client The local Java client Nothing

master • awcomm The stopso master command

• AgentService doesn't stop any actual processes,
• awapi but it does put the Automation
Engine into a Stopped status.
It also enables the Automation
Engine to start if stopped previously
and starts any non-running non-
stopped Agents (Agents in a
TROUBLE status).

rmi • awcomm • RmiServer (if issued on the

• AgentService (which starts Automation Engine)
-or-
awapi)
rmiserver • RmiServer (if issued on the
Automation Engine).

watchworx • The local watchworx process • The local watchworx process

• awcomm • AgentService (which stops
• AgentService (which starts awapi)
awapi) • RmiServer
• RmiServer

The watchworx Process

Applications Manager supports most production environments without any problems. However, in situations where
network or database problems are frequent, or machines and applications are in constant flux, WatchWorx ensures
the Applications Manager processes are up and running. WatchWorx is an Applications Manager program that
checks to make sure Applications Manager processes are running, and restarts the processes if necessary.
WatchWorx checks the awcomm, AgentService, and RmiServer processes. If these processes exits
unexpectedly, WatchWorx will restart the process. If a process has been stopped manually by systems or
operations personnel using the stopso command, WatchWorx will not start the process.
Restarting a Remote Agent's AgentService process may take 7 to 10 minutes. This time depends on the time it
takes to cycle through the WatchWorx process, the connection of the network, and the speed of the machines.
 Applications Manager 9.4.1

Applications Manager processes write to the watchstatus.log file in the log directory once every sleep cycle.
Sample entries from a watchstatus.log file are shown below:

PROD1 awcomm Online 20051116084942

PROD1 agentservice Online 20051117093404
PROD1 rmiserver Online 20051117091006

UNIX vs. Windows

In UNIX (and Linux), WatchWorx only runs as a detached process for each Agent installation (one per
AgentService).
In Windows, WatchWorx runs as a service on each Automation Engine and Remote Agent (watchworx.exe in Task
Manager). If you have an Automation Engine and three Remote Agents, there would be four WatchWorx services:
one on the Automation Engine, and one on each of the three Remote Agents.

WatchWorx Environment Variables and Terms

WatchWorx variables can be set in the awenv.ini file located in the Applications Managersite directory, under the
section [WatchWorx]. This section can be created if it does not exist. The following variables can be set in the
format variable=<value>.
WatchWorx Variables
The WatchWorx variables are described below.

Variable Description Default Value

initial_sleep The initial time WatchWorx waits for UNIX: 120 seconds
all processes to start.
Windows: 20 seconds

watch_sleep The WatchWorx sleep time between 30 seconds

process checks.

mult_factor When a process no longer exists, 7

WatchWorx compares the latest
status update time period to the
sleep_time * mult_factor.
By default, WatchWorx uses a
mult_factor equal to 7. If process
sleep time equals 60 seconds,
WatchWorx will not act on an idle
Agent unless the time difference has
exceeded 420 seconds. WatchWorx
does not restart processes that have
been properly shut down due to User
intervention.

max_cycles The max_cycles variable sets the 3

number of times WatchWorx will
attempt to restart the process every
x number of seconds as set by the
min_time_reboot variable. After the
specified number of restarts, it will
try to restart the processes every
x number of seconds as set by the
max_time_reboot variable.

max_time_reboot Maximum time to wait between 1800 seconds (30 minutes)

restart attempts.
 Applications Manager 9.4.1

Variable Description Default Value

min_time_reboot Minimum time to wait between 300 seconds

restart attempts.
(5 minutes)

watch_wait Sleep time between issuing a stopso 3 seconds

command and a startso command

watchstatus_file Names the WatchWorx process If no file name is specified

status log file. Must be a fully watchstatus.log in the log directory
qualified path. For example: is used
/u01/product/am/log/
watchstatus.log

Process Statuses: Offline/Online

There are two valid statuses for Applications Manager processes that WatchWorx recognizes: offline and online.
• Offline indicates a process that was stopped manually. WatchWorx does not attempt to restart offline processes.
• Online indicates a process that was started automatically. WatchWorx will attempt to stop and restart any online
process that fails to update its time stamp within the specified time interval.
These statuses are stored in the watchstatus.log file in the log directory. Sample entries from a watchstatus.log
file are shown below:

PROD1 awcomm Online 20051116084942

PROD1 agentservice Online 20051117093404
PROD1 rmiserver Online 20051117091006

Sending Process Restart Notifications with WatchWorx.notify

WatchWorx allows you to add actions via the WatchWorx.notify script (WatchWorx.notify.bat for Windows). The
WatchWorx.notify script will be run every time WatchWorx tries to restart an Applications Manager process (this
will happen if the process seems to be hung or goes down unexpectedly). The script must be placed in the exec
directory. In UNIX, the script must be given execute permissions.
Three arguments can be passed from WatchWorx to the script:
• Process name
• Process type
• A message from the WatchWorx program regarding the action
For example, the following UNIX script sends an email or page to the Applications Manager administrator:

$cat WatchWorx.notify

#This script notifies Administrator a Applications Manager process went down.

echo "`date`Applications Manager process $1 of type $2. WatchWorx message: $3.
"|mail [email@address]

The results from this script would look something like the following if they were sent in an email:

Fri Mar 22 16:39:14 PST 2002 Applications Manager process MYNODE of type AgentService.
WatchWorx message: Last updated 421 seconds ago and will be restarted immediately.
 Applications Manager 9.4.1

Customizing WatchWorx in a Windows Environment

The WatchWorx service for Windows checks Applications Manager processes, and restarts them when applicable.
By default, WatchWorx starts the server stack when you boot-up the Automation Engine or an Agent machine.
It does not start the Automation Engine or Agents as this may not be desirable for all users or situations. This is
especially true when the machine has been down for a while or is coming back from a system crash. However,
Applications Manager allows you to customize this behavior using an %AW_HOME%\bin\watchstart.bat script.
If a watchstart.bat script exists, WatchWorx runs it on startup. For convenience there is a template watchstart
script provided by Applications Manager. Here is a brief description of how the Applications Manager provided
template script works. When running from an Automation Engine, the script first checks to make sure the database
is up. If so, it issues a startso command to start all the local processes. When running from a Remote Agent there
is no database check needed. It simply issues the startso command, which will start all the remote processes.
Setting-up the watchstart.bat Script
The watchstart.bat script is not included in the bin directory when you install Applications Manager. To activate it,
you copy the template script named watchstart.hold and modify it to meet your needs.
You can add start-up tasks to your watchstart.bat script. One common addition is to ensure that the RMI Server
is started on the Automation Engine. This can be done by adding the following line at the end of the Automation
Engine section:

startso rmi

Use care when adding additional modifications. Incorrect modifications may cause the Applications Manager
processes to fail to start properly. Also, long running tasks must be avoided as they could cause the service start/
stop to report a Windows error that the service is not responding.
Since watchstart.bat is a user-customizable script, it will not get overwritten on upgrades. You will get a new
watchstart.hold file when upgrading, but not a watchstart.bat file.
Setting-up the watchstop.bat Script
There is a watchstop.bat script that the WatchWorx service runs when the service stops. There is a template
%AW_HOME%/bin/watchstop.hold script you can copy and customize to meet your needs as well.
The watchstop.bat script will be run as the WatchWorx service is stopping. However, if the machine is being
shutdown there is no guarantee that all the Applications Manager services will have time to cleanly exit before the
machine shuts down.

WatchWorx in Action
WatchWorx checks to see if the Applications Manager processes are running, and restarts them if necessary. If
all processes are writing regularly to the WatchWorx status files, WatchWorx sleeps for 60 seconds, then checks
again. WatchWorx continually monitors processes as explained below.
WatchWorx Actions
WatchWorx takes actions based on the type of process and the time difference between the current time and
the time in the status file. There are two groups of processes, and WatchWorx handles the RmiServer process
differently than the other processes.
WatchWorx acts on the RmiServer process as follows:

If RmiServer is: And the process (PID): And the time difference Then WatchWorx:
is:

Online Exists Less than process Sleeps for 60 seconds,

sleep_time*factor then rechecks.

Greater than process Launches the WatchWorx

sleep_time*factor notify, stopso, and
startso commands to
restart the process.
 Applications Manager 9.4.1

If RmiServer is: And the process (PID): And the time difference Then WatchWorx:
is:

Does not exist N/A Launches the WatchWorx

notify, stopso, and
startso commands to
restart the process.

Offline N/A N/A Sleeps for 60 seconds,

then rechecks. No action
needed since processes
are stopped.

WatchWorx acts on the other Applications Manager processes as follows:

If a process status is: And the tIme difference is: Then WatchWorx:

Online Less than Sleeps for 60 seconds, then

rechecks.
process sleep_time*factor

Greater than Waits for the number of seconds

specified by mult_start*sleep (420
process sleep_time*factor
seconds by default), then launches
the WatchWorx notify, stopso, and
startso commands to restart the
process.

Offline N/A Sleeps for 60 seconds, then

rechecks. No action needed since
processes are stopped.

The awcomm Process

The awcomm process provides a port directory service on the Automation Engine machine. It stores the port
assigned to the Automation Engine, and makes it available to client processes. There is no awcomm process on
Remote Agent machines. Under a typical configuration, there is only one awcomm process on the Automation
Engine machine.
Under normal circumstances, awcomm never needs to be stopped unless you plan on removing its Applications
Manager instance.
Starting Routine
The awcomm process is the first process that is brought up when you execute the startso command if it is not
already running. It reads recovery information from the net_conn.dat file in the data directory.
It handles requests from the AgentService and RmiServer processes. The process needs to be present and
functional at all times for any communications to occur.
The RmiServer process re-registers with awcomm every 30 minutes and will restart awcomm if not found.
Listening Ports
By default, the awcomm process listens on port 2136. When firewalls are in place, the port must be opened for
inbound communications on the RMI server.
Port 2136 is registered with the Internet Assigned Numbers Authority, so you should not need to change it. If you
do need to change the port number, edit the following parameters in the awenv.ini file on the Automation Engine
and all Agent machines, add or modify the following line under the [default] section:

AWCOMM_PORT=<port number>

The awenv.ini file is located in the Applications Managersite directory.

 Applications Manager 9.4.1

To check if a specific port is being used, issue the following command:

netstat -an|grep <port number>

Dependencies
The port that awcomm uses must not be in use by another process.

The AgentService Process

The Applications Manager internal communications processes are handled by the AgentService process.
The AgentService process starts and finds the first available port in the range 49152-65535 and registers its
Automation Engine information with the Automation Engine's awcomm process so future client connections can be
directed its way.
Configuring AgentService
To configure the AgentService process, you can set the following variables in the awenv.ini file in the site
directory:

Variable Description

AgentClientPort A port on a Remote Agent that accepts incoming data

from the Automation Engine.

master_ip_address The IP address of the Automation Engine.

Troubleshooting
If the Applications Manager database is not running or the RmiServer process is not available, the AgentService
process will report errors.
AgentService Can Use any RMI Server for Database Connections
When the AgentService process starts, it attempts to connect to the IP address for the RmiServer process
specified in the master_ip_address setting in the awenv.ini file.
If it cannot connect to the primary RmiServer process, set with master_ip_address, it will then try to get an IP
addresses for an alternate RmiServer process from its local file RmiServers.dat located in the data directory.
While the AgentService process is running, it checks once per sleep time (by default 60 seconds) for any new
RmiServer processes that have started running, and will add these to the RmiServers.dat file.
If connection is lost to the primary RmiServer process, AgentService will connect to the first available alternate
and make it the new primary.

The RmiServer Process

The Applications Manager RMI server is the process that serves out information to the Applications Manager Java
client. It gets its Oracle database connection information from AgentService and decrypts its login information from
Masters.properties. If the RMI Server is not active, the Applications Manager Java client will not start.
Starting Routine
The routine is started with the call startso rmi. This calls the Java Virtual Machine. The RMI server will start and
bind to the RMIRegistryPortNumber specified in the Options.properties file.
The location for the Options.properties file is:
UNIX:

$AW_HOME/web/classes
 Applications Manager 9.4.1

Windows:

%AW_HOME%\web\classes

The Applications Manager RMI server gets the database connect information from the awcomm process (DB_IP,
DB_SID) and tests out its database connection.
After connecting with awcomm, the RmiServer process will try to connect to the Applications Manager database.
It will continue trying until the connection is made. The RMI Server cannot come up successfully if the database
information is not correct.
Dependencies
For the RmiServer process to work correctly, the following conditions must be met:
• The awcomm and Automation Engine's AgentService process must be up and running to get the database
SID (or PDB service name for Oracle 12c and above) connection information.
• Net8 (SQL*Net) must be running for the RMI server target database.
Configuring the RMI Server
There are two configuration files associated with the RMI Server: Options.properties and Masters.properties.
the Options.properties and Masters.properties files are located in the following directories:
UNIX:

$AW_HOME/web/classes/Options.properties

$AW_HOME/data/Masters.properties

Windows:

%AW_HOME%\web\classes\Options.properties

%AW_HOME%\data\Masters.properties

The Options.properties file is a series of parameters similar to the awenv.ini. It is not divided into sections. If a
value is set twice, the last entry listed in the file will be used.

Variable Description

RMIHostID The IP address of the machine the RMI Server resides

on.

RMIRegistryPortNumber The port used by the RMI Server.

RMIDataPortNumber The port used for data by the RMI Server.

ServerCodebase The URL path where the UserWorx.jar resides.

 Applications Manager 9.4.1

Variable Description

ServerLog The log where all the normal log information and debug
information is set.

Debug Debug setting. Default is false.

SSL Set Secure Socket Layer security on or off. Default is

on.

ExitPage Page that clients will be sent to after they leave the
client.

SQLOPER_HOME Applications Manager installation location (AW_HOME).

The Masters.properties file provides Automation Engine names for the Applications Manager Automation
Engines. The Masters.properties file includes one required line for this Automation Engine with optional lines for
additional Automation Engines. When additional Automation Engines are listed they are:
• Added to this Automation Engine's RMI server.
• Selectable from the Automation Engine drop-down list on the Login window of for this Automation Engine.
Troubleshooting
The following can cause problems for the RMI Server:
• Net8 (SQL*Net) is not running or the database connection is not running.
• Java is not installed or the patch level of the OS is incorrect.
• There are firewall problems between the client and the RMI server.
• Incorrect values for any of the following variables in the awenv.ini file, MasterServerPort, DB_SID, DB_IP,
DB_PORT.

Task and Program Execution

Task execution begins with the Automation Engine determining that a task is eligible for execution and ends with
the Automation Engine initiating program execution. The awexe program is a utility used during program execution.
Task Execution
Task execution brings into play the management and transaction processing processes. It begins when the
Automation Engine determines a task is eligible to run, and ends when the program terminates and its completion
status and any outputs have been logged into the Applications Manager database.
The steps in the execution process are described below.
1. The Automation Engine monitors the Backlog and determines that a task is eligible to run.
2. The Automation Engine collects the necessary data to run the task.
3. The Automation Engine initiates the program execution sequence by requesting the AgentService process. The
AgentService process creates the pr (task parameters) and pm (task environment variables) files. The pm file
initiates the BODY script.
Program Execution
After the Automation Engine has collected all the required information to run a task, it initiates the program
execution sequence by requesting the AgentService process to create the pr (task parameters) and pm (task
environment) files and launch the pm script. The sequence ends when the task is done executing.
During execution:
• The awexe program is a utility used to communicate with the Applications Manager repository through the
AgentService process.
For more information on awexe, see The awexe Process.
• The AgentService process monitors tasks to make sure they do not exceed their maximum run time, and to
ensure that they complete.
The steps in the program execution process are described below.
 Applications Manager 9.4.1

1. The Automation Engine launches the pm script through the AgentService process that runs the BODY script.
The BODY script runs any prefix run-time extension scripts and runs the Program Type script. It also notifies
the AWAGENT process that a task has been submitted. For more information on the BODY script and Program
Type script, see BODY.
2. BODY calls the awexe awprint command to log the system output.
3. BODY calls the awexe process to update the task's status to running.
4. The AgentService process monitors the task process for maximum run time and completion.
• If the maximum run time assigned to the Applications Manager Job for the task is exceeded, AgentService
will try to kill the task.
• If the task process disappears before AgentService has received a completion status, AgentService
changes the status of the task to DIED.
5. Task outputs are logged and/or printed by Applications Manager Program Type scripts or customer User scripts.
6. BODY calls awexe to report the task's final status.
7. BODY exits.

The awexe Process

The awexe process is what is known as a 'thin' client. It connects to the AgentService process. The awexe
process can only run items that are listed in the awserver_sql.dat and awserver_sqlusr.dat files in the
Applications Managerdata directory. The proper variables (AW_HOME, AGENT, PATH=$AW_HOME/bin:$PATH)
must be set for them to execute correctly, an Applications Manager User must exist that matches the OS user,
and the User must have the correct Awexe Range. Awexe calls are used for the install, import and export, the
command line utility, task starting and completion, startso and stopso, etc.
Starting/Running Routine
The awexe process submits requests to AgentService. To see if the OS user can execute the statement, the
AgentService process validates the operating system (OS) user and the awexe command number against the
range of allowable commands assigned to the User. If the permissions are correct, the statement is executed and
the results are passed back to awexe.
AWEXE Ranges
When you define a User in Applications Manager, you can limit the commands a User can issue by setting a value
in the Awexe Range field. Ranges are listed below:
• 1000-1999: Used for Applications Manager background processes.
• 2000-2999: Utilities for the general User.
• 3000-4999: Reserved for consulting.
• 5000-9999: Used for custom definitions.
If you enter 2000-2099, the User will have access to all the Applications Manager command line interface functions.
However to change any data, they will be required to supply an Applications Manager User name and password.
For more information on the command line interface, see the Development Guide.
The awexe range can be a comma separated list of multiple ranges.
Example: 1000-1999,3000-3999
Troubleshooting
Problems with awexe can be caused by:
• AgentService processes in the backend are not running
• Variables not set correctly
• Commands taking too long to execute
• OS user not set up correctly
• Applications Manager User not having the authority (correct Awexe Range) to execute a function
• The OS user not having read access to the Applications Managerc, bin, and exec directories and read/write
access to Applications Manager "pipe" directory
 Applications Manager 9.4.1

How a Task Runs

A task begins when a Job is requested or scheduled to run. The Automation Engine initiates the program execution
and notifies the appropriate Agent. Thousands of individual tasks (and associated programs) can execute at a
single time. This chapter focuses on the actions of a single running task.
The image below shows the general stages involved in processing a task.
 Applications Manager 9.4.1

The submittal stages (down arrows) set the initial status, create the run-time environment, and pass information.
The return stages (upward arrows) handle registration of task output, post-processing, and conditions. Each stage
is explained in detail in this chapter.
Overview of the Diagram
The process starts when a task is set to run by being scheduled or requested waking up the Automation Engine.
The Automation Engine passes tasks eligible for execution to the appropriate Agent. The Agent processes the task
by creating and executing a script. The script establishes the task's environment, executes any run-time scripts,
and launches the Program Type script.
The Program Type script launches the application and performs the handshaking between Applications Manager,
the program, and the running application. All the while, the Automation Engine performs any DURING conditions.
After program execution, the outputs are (optionally) registered. When the output is registered, a link between the
output file and the running task is created and stored in the Applications Manager database. After registration,
run-time extensions execute before reporting the tasks completion status. The Automation Engine performs any
AFTER or DELETED conditions. A record of the finished task is written to History. These stages are described in
detail in the remaining topics in this chapter.
Stage Bar
Each topic contains a stage bar that summarizes the key component for each stage of a task's execution. The
arrow indicates the execution direction. This is important since the stages are bi-directional, meaning stages are
executed before, during, and after the program executes. Think of a task's execution as a series of scripts that
call sub-scripts that pass in parameters and pass out results. An example stage bar for the Automation Engine is
shown below.

Request to the Automation Engine

Tasks are initiated via schedule or request.

The task running process starts when a task is set to run by being scheduled or requested waking up the
Automation Engine. Tasks can be requested from when:
• Ad hoc requests are made from the Requests window.
• The the awrun command is issued from the command line or a script.
• An API call is made.
• Tasks are inserted into the database.
When a task is submitted, an entry is made into the SO_JOB_QUEUE in the Applications Manager database. The
Backlog shown in the Explorer window is a graphical representation of the SO_JOB_QUEUE in the Applications
Manager database.
Before a task starts, the Applications Manager Automation Engine analyzes a task's characteristics for eligibility to
run. The characteristics include predecessor requirements, single run, priority, start time, Queue threading, Agent
Groups/load balancing, Agent threading, and Agent availability.
If a task is eligible to run, the Automation Engine evaluates any BEFORE conditions and determines if the task may
run. True conditions using the actions WAIT UNTIL MET, DELAY TASK, RESCHEDULE TASK, SKIP TASK, and
HOLD TASK may potentially delay or preclude a task from running.
If the conditions do not preclude the task from running, the Automation Engine locates the Agent based on the
Agent or Agent Group assigned to the task and notifies the Agent. The Applications Manager Automation Engine
then changes the task's status to STARTING.
The Automation Engine creates two files: pm and pr. The pm file creates a new environment and launches the
BODY script. The pr file contains the values supplied for each task prompt, which may be used in the Program
Type interface script or program.
pm File
Before the Automation Engine has the Agent execute the pm script, it directly sets two Environment Variables:
db_login2 and db_password2. These are set directly so that they never exist in a file on the operating system.
 Applications Manager 9.4.1

The Agent launches the pm file which sets the environment and exports the environment settings to the new
environment. Then the pm file launches the BODY script.
pr File
The pr file contains the arguments from the task prompts. The filename of the pr file (pr.<seq_no>) is exported
by the pm file under the system Environment Variable par. The full path name for the file is stored the variable
so_par. The par file is always in the run subdirectory under AW_HOME and can be (optionally) used in your
program or Program Type scripts.
Both the pm and pr files are deleted by the BODY script after a task executes, but all information pertaining to a
task is displayed in the task's corresponding SYSOUT file.
Setting and Exporting Environment Variables
You can set Environment Variables and export them (make them available) for a program in four places:
• The sosite file located in the site directory.
• PREFIX run-time extensions
• Program Type interface scripts
• Environment Variable objects defined in the Applications Manager client. For more information, see the
Development Guide.
Applications Manager defines approximately 40 environment variables at run time and writes their values to the pm
file. When creating an environment variable in sosite, keep in mind that the Applications Managerpm file creates
and exports the values for these 40 variables. A listing of all Applications Manager environment variables can be
found in the Development Guide.
Therefore, if you define an environment variable in the sosite file such as OUTPUT, it is automatically overwritten
by the pm file at run-time. You may alter the value of OUTPUT after the pm file executes using a PREFIX script or
Program Type script.

pm File
The pm file sets environment variables for the task and its related sub-objects.

The pm file sets environment variables for the task and its related sub-objects (Database Logins, Program Types,
output specifications). After setting the sub-shell's environment, it launches the BODY script.
To modify Applications Manager environment settings, you can add or delete environment variables from the site/
sosite file in UNIX or the site\envvar.bat file in Windows. You can also create PREFIX scripts that can add, modify,
or remove environment variables. These occasionally include Oracle specific variables such as ORACLE_SID,
ORACLE_HOME, and TWO_TASK.
pm Script
BODY deletes the pm file after the task completes. A portion of a UNIX pm script is shown below.

$ cat pm790.sh
module='CHUCK_SCR2'
par=pr790.sh
so_par=$AW_HOME/run/pr420.sh
jobid=292.00
#(more environment variables)…
log_run=Y
login_sid=''
full_login='';export full_login
user='SQLOPER'
printer_type=ANY
export runfile par host_command so_par
export module source app_path command_dir
 Applications Manager 9.4.1

export BATCH_HOME OUTPUT queue command

#(more exports)…
export net_connect db_type chain_seq chain_id
sh $AW_HOME/exec/BODY 1>/dev/null 2>&1 &
exit 0

Using seq_no in Multiple Locations

Applications Manager assigns a unique run ID number (job_id) and sequence number (seq_no) to each submitted
task. The job_id is used to generate the names for a task's output files. The output files are deleted regularly by the
SYSTEM Process Flow. The pr and pm files are deleted after the program runs (unless DEBUG is enabled). The
following table highlights these related objects.

File Name Action/Description Directory

pm<seq_no>.sh Passes system environment exec

variables.

pr<seq_no>.sh Passes prompts. exec

o<run_id> (UNIX) Default system output file: Produces out

receipt of the pending task.
o<run_id>.log (Windows)

b.<run_id> (UNIX) Default report file for the program: out

Records results generated by the
o<run_id>.lis (Windows)
program.

BODY
The BODY script sets the task status to RUNNING, registers system output, executes any PREFIX scripts, and
launches the Program Type script.

The BODY script initially sets the task status to RUNNING, logs the task's process ID (pid), notifies the Agent of the
task so it can monitor the task to completion, registers system output, executes any PREFIX scripts, and launches
the Program Type script. BODY creates the system output file immediately so that you are able to view it as a task
executes. BODY creates a print registration file that contains the information required for Applications Manager to
register the system output.
On Windows, there are three BODY scripts, body.bat, body2.bat, and body3.bat.
Viewing Output
You can view system output from History in the Explorer window or the Output window by right-clicking on the
selected task.
Run-time Extension Scripts
The BODY script also runs User-defined scripts at various times in a task's execution. These are referred to as run-
time extensions. Any valid shell or batch script can be used as a run-time extension as long as the script is stored
in the exec subdirectory under the AW_HOME directory and named appropriately.
The first run-time extension script executed is the SYSOUT script. Before a task runs, Applications Manager
executes appropriate PREFIX scripts if found. The remaining scripts (COMPLETION, SUCCESS, and TROUBLE)
execute after the program executes. The image below indicates the location of these scripts. For a detailed
explanation of run-time extensions, see the Development Guide.
 Applications Manager 9.4.1

Warning: SYSOUT, PREFIX, COMPLETION, TROUBLE, and SUCCESS scripts are invoked in-line. Poor
or improper code in these scripts can adversely affect the ability of Applications Manager to properly control
and monitor the task's execution. For example, an 'exit' in these scripts can cause task status to change to
DIED.

Program Type (before program execution)

The Program Type script generally passes the par file's content to the program.

The Program Type and its matching script generally pass the par file's content to the program. Program Types
are objects that optimize development and maintenance efficiency when a family of programs are consistent in
the way they accept input and produce output. The Program Type object specifies the Program Type script. The
Program Type script performs the handshaking between Applications Manager and the program to be executed,
and processes any program outputs. You can define as many Program Types as needed.
Program Type scripts are located in the exec subdirectory under the AW_HOME directory. In the image below, the
SQLP Program Type calls the SQLP Program Type script.
For information on Program Types, see the Development Guide.
 Applications Manager 9.4.1

Program
The program executes and returns its exit status to the Program Type script and may create output.

The program executes and returns its exit status to the Program Type interface script and may create output. The
program passes the status value to the Program Type script and performs (optional) error checking and output
processing. Generally, the Program Type is responsible for registering the output. This is explained in Program
Type (after program execution).
Standard Output File
The program's standard output is normally redirected into the task's log file. However, some Program Type scripts
may redirect the output to a file and register it.
Program Output File
 Applications Manager 9.4.1

The program output file contains the actual information from the program. A program can generate any number of
program output files. The default location for program output is the out subdirectory on the Agent.

Program Type (after program execution)

After the program completes execution, the Program Type script captures output and ensures that files are properly
registered.

After the program completes execution, the Program Type script captures output and ensures that files are properly
registered. Notice that execution in the diagram above is now moving from right to left.
The interaction between your program and Program Type affect where a specific task is executed. Generally, the
program generates and returns the exit status to the Program Type script. Either the program or Program Type
script may generate output depending on how these are set up.
Any output from a program that is written to standard out will be captured in the system output file. If the program
creates any additional output that needs to be registered with Applications Manager, the Program Type script can
call FILESIZE.
FILESIZE
FILESIZE creates a file that contains the information required for Applications Manager to register the output file(s).
By default, the output goes to $file or %file%. The default paths for file are given below.

Output UNIX Windows

Standard out (log file) $AW_HOME/out/o<job_id> %AW_HOME\out\o<run_id>.log

Program output $AW_HOME/out/b.<$job_id> %AW_HOME\out\o<run_id>.lis

BODY (after return from Program Type script)

BODY checks if the elapsed time is less than the min_run_time. If it is, then BODY aborts the task and Applications
Manager sets the error status equal to 1.

After the Program Type completes, BODY tests the 'Minimum-Run-Time' as defined in its Job definition. If the
elapsed time is less than the minimum run time, then the task aborts and Applications Manager sets the error
status equal to 1.
BODY runs any defined run-time extension scripts (COMPLETION, TROUBLE, and SUCCESS) if they exist.
You can create a TROUBLE script that resets the error status before passing the results back to the Agent. For a
detailed explanation of run-time extensions, see the Development Guide.
BODY updates the tasks completion time, return code, and completion status. After checking that all files have
been successfully moved, BODY deletes the pr and pm files.
Finally, BODY deletes any other temporary files created.
The Automation Engine performs the next stage in task processing.

Automation Engine
The Automation Engine performs any AFTER or DELETED conditions. A record of the finished task is written to
History.

The Automation Engine performs any AFTER or DELETED conditions. A record of the finished task is written to
History.
For more information on condition statements, see the Development Guide.
 Applications Manager 9.4.1

At this point, execution of the task is complete.

Troubleshooting with Log Files and Debug

A basic log file is generated for each task you run. It is stored in the Applications Managerout directory. This log is
useful for troubleshooting Jobs, Process Flows, and run-time scripts.
• You can add significant detail to a task's log by activating the Applications Manager debug utility.
• You can turn on debug for selected Applications Manager programs.
• Applications Manager generates error and log files for each Applications Manager Automation Engine and client
process. These are stored in the Applications Managerlog directory.
• Applications Manager generates log files for the Applications Manager Java client, Java Web Start, and RMI
server. These are stored in the Applications Managerlog directory.
Knowing Where to Look to Troubleshoot
When troubleshooting, consider the type of problem you are experiencing in order to determine the files you need
to look at or provide for Broadcom Support. Each form of debug is described in detail in this chapter, but the types
of debug most commonly needed are summarized in the paragraphs that follow.
If there is a problem in the Applications Manager client or Automation Engine (the Java processes), then look at the
RmiServer.<timestamp>.log file located in the log directory. The Remote Method Invocation (RMI) server is the
Java process that runs the Applications Manager client. You should also keep in mind that the Automation Engine
is also part of the RMI process (both are in Java).
When you get the Automation Engine log file, search it for strings that mention errors by including AwE (note the
lowercase "w").
Note that you can turn on RMI Java debug via the Applications Manager client by selecting About Applications
Manager from the Help menu. You can also turn it on via the awenv.ini file by entering Debug=true. For more
information on setting server debug, see Setting Server Debug.
If there is a problem starting or stopping the backend processes, you should look at the corresponding file for the
process in the log directory. Search these files for text strings including ORA or ERR. It is also important to look for
time gaps.
If there is a problem with a task, then check out the task's system output file. You can turn on task-level debug
by creating a 0-byte file in the debug directory named BODY. Once the BODY file is created, you simply run
the task again. The debug information will be included in the task's system output file. For more information, see
Applications Manager Standard Out Log Files and Program Debug.
With any form of debug, when you get the information you need, turn debug off to save space.
Running the Program or Script Independent of Applications Manager
Some newly created Jobs abort because the program or script they run fails. If a Job aborts, it is always a good
idea to try and run the program or script from the command line to verify whether the problem is in the program or
Applications Manager.

Applications Manager Standard Out Log Files and Program Debug

Every time Applications Manager runs a task, it captures the standard out log file and places it in the out directory
in AW_HOME.
As you begin to use Applications Manager and you start developing Jobs, Process Flows, and run-time scripts, you
will invariably have the need to troubleshoot your work. Applications Manager provides logs for each task you run
as well as logs for the Applications Manager processes. The Applications Manager debug utility adds more detail to
the logs.
Standard Log Files
When Applications Manager runs a task, it captures the system's standard out log and places it in the Applications
Managerout directory. The log contains information that is useful for troubleshooting a Job. A sample UNIX
standard out log is shown below.

Body Started at Tue Feb 5 06:18:05 PST 2002

awprint PRINT -j 2000033.00 -n o2000033.00 -p SYSOUT -d /appworx/out
 Applications Manager 9.4.1

Process Id is 18077 on Tue Feb 5 06:18:06 PST 2002

source SOSHELLS program /appworx/exec/test_module
Operator BILLV51
application BATCH module TEST_JOB job_number 19
jobid 2000033.00
batch_home appworx output appworx/out rpf_options printer TEST
app_path /appworx
file b.2000033.00 command_dir /exec copies 1 user SQLOPER
function STORE log run Y output required N
db_type ORACLE db_login billsv51 net_connect

parameter file
5
End of parameter file
starting at Tue Feb 5 06:18:06 PST 2002
complete at Tue Feb 5 06:18:11 PST 2002
return code = 0
*****************************
* Finished on Tue Feb 5 06:18:11 PST 2002 with status FINISHED (FINISHED)
*****************************
awprint PRINTSIZE -j 2000033.00 -n o2000033.00 -d /appworx/out
Tue Feb 5 06:18:14 PST 2002 Done with BODY

The Windows standard out log is similar.

The standard log file includes basic information about the task such as:
• The name of the program executed
• The person (operator) who ran the task
• The Applications Manager run id assigned to the task
• The parameters used to run the task
• A record of the basic steps taken to execute the task
The standard log file is a good place to start your troubleshooting.
File Naming Conventions
In UNIX and Windows, the standard out log files are named using the following pattern:

o<run_id>.log

Turning on Task and Program Debug

You can also turn on debug for the following selected programs by creating the appropriate file in the Applications
Managerdebug directory:
• AgentService
• API_RECOV
• AWJAVA
• BODY
• EXECSG
• FILESIZE
• FTP.SH
• IMPEXP
• ISQLP
• JAVA
 Applications Manager 9.4.1

• JOB_COMPLETION
• KILLJOBS
• PRINTEM
• PRINTEM2
• PRINTRECOV
• REGISTER_LOGS
• SQLP
• KILLSERVER
• SYS_PRINT
• cat_dir
• startoper
• stopoper
• stopso
For example, to turn on debug (which will show up in the task's output) for PRINTEM on a UNIX system, you would
create a $AW_HOME/debug/PRINTEM file.
Creating a JAVA file on the Automation Engine machine turns on RmiServer and AgentService debug in the
same file. You can also turn on AgentService debug for a particular Agent by checking the Agent debug box in
that Agent's definition. For more information, see Defining Remote Agents.

Background Process Logs

If you suspect there is a problem with the Applications Manager background processes, you can check the logs for
the following background processes. The AgentService process runs on all Agents. The awcomm process runs
on the Automation Engine machine. If WatchWorx is enabled, there will also be a watchworx processes running.
Normally an additional process called RmiServer will be running on the Automation Engine machine.
The files are stored in the log directory in AW_HOME. You can view logs for all processes running on an Agent,
or the RmiServer logs for an Automation Engine by right-clicking the Agent or Automation Engine in the Explorer
window and choosing View Log from the popup menu.
File Naming Conventions
By default, Applications Manager generates two basic log files for each process. The error files are named using
the following convention:

<process>_<timestamp>.err

The log files are named using one of the two following conventions:

<process>_<timestamp>.log
<process>.<timestamp>.log

Several sample log file names are listed below.

AgentService_0511201552.log
RmiServer.0511211056.log
watchworx_051118155234.err
watchworx_051118155234.log
 Applications Manager 9.4.1

The timestamp for a log is in the following format:

YYMMDDHHMM (years, months, days, hours, minutes)

For example, 0511201552 represents the 20th of November 2005 at 3:52 P.M.
Automatic Log Rollover and Zip
When log files grow above 50 megabytes, Applications Manager automatically rolls them over. When Applications
Manager finishes writing to a log, it auto-zips it to save disc space.
How Long Logs are Retained
By default, process log files are retained for seven days, then deleted. New process log files are started every 24
hours. You can modify these settings by defining two variables in the [default] section of the awenv.ini file to apply
to the log files for all the background processes or you can define the variable under one of the process sections to
apply it to that process only.

Variable Description

LOG_RETENTION_DAYS Sets the number of days a process log file will be

retained. The default is seven days.

ROLLOVER_INTERVAL Sets how often a new log file will be created. The value
is expressed in minutes. The default value is 1,440 (24
hours).

These settings don't change retention days for output files. Job retention is controlled by the Retention days
setting on each Job's Output tab.
Logging the Purging of Log Files
Applications Manager logs the purges RmiServer and AgentService log files. This is because log files
can be deleted because of total size as well as age. A purge log is created each day. Its name format is
RmiServer_purgeLog_<timestamp>.log or AgentService_purgeLog_<timestamp>.log. Each entry contains a
timestamp followed by the file name. The purge logs themselves get purged when they are older than the setting
specified in the ServerLogRetentionDays setting in the awenv.ini file (default of 7).

Setting Client, Server, Oracle Trace, and All Agent Debug

You can select client, server, SQL trace debug options from the About Applications Manager window in the
Applications Manager client shown below.
 Applications Manager 9.4.1

The debug options are:

• Client: Debugs Java used on the client machine. You may need to turn on client debug when you are getting
errors in pop-up windows while using the Applications Manager, or when the Applications Manager client hangs.
When you turn on client debug, it is also a good idea to turn on server debug, because server debug errors
often accompany client errors. Turning on client debug is a two-step process. You determine where to write the
debug information and activate debug. Debug information can be written to a client machine in either a Java
Console window, or a log file. When this box is checked, client debug is activated for an individual user's client
machine. A setting in the Options.properties file allows you to activate client debug for all users who log into an
Applications Manager Automation Engine.
• Server: Debugs the RmiServer process. When this box is checked, debug information from the current RMI
server session is written to the RmiServer.<timestamp>.log file. When you turn RMI debug on from here,
the logs are limited to the current session (in other words, what's going on right now with the RMI server and
Automation Engine). A setting in the awenv.ini file allows you to see all of the information the RMI first loads on
start-up.
• SQL: If you want to see what SQL is executed by the RmiServer process, you can turn on Oracle trace.
Normally you shouldn't need to turn on general SQL trace for the whole product, because you can determine
which SQL statements or procedures are having problems and trace only those statements or procedures.
Debug information will be written to the trace files in the $ORACLE_HOME/rdbms/log directory.
• Agent: When checked, debug information is written to the AgentService.<timestamp>.log file for every
running Agent. Agent debug can also be written for a single Agent when either debug=true is set in an Agent's
awenv.ini file or when the Agent debug box is checked in an Agent's definition.
You open the About Applications Manager window by selecting About Applications Manager from the Debug
menu on the Applications Manager desktop.
Java Garbage Collecting from the Applications Manager Client
 Applications Manager 9.4.1

You can do a Java garbage collection to free up heap memory that is no longer needed by clicking Java Garbage
Collection under the Debug menu on the About Applications Manager window. This will only send a hint to
Java, so it doesn’t force it to collect everything.

Setting Client Debug for One User

To turn on client debug, set debug=true in the client.properties file in Applications Manager client directory on
your PC.
It is also possible to set client debug from the About Applications Manager window once you are logged into the
client. However, it is advantageous to set it here, so that debug is on for the client start-up.
The client log sub-directory includes the following files:
• client.log: Includes all client standard and debug logging up until you click OK on the Logon window.
• <master or connection name>_client.log: Includes all client standard and debug logging for your client
session.
You can optionally write to a different client sub-directory other than log using the logDir setting in the
client.properties file.
To turn debug off, comment out debug=true in the client.properties file like the following.

#debug=true

Setting Client Debug for All Users

Turning on client debug is a two-step process. You determine where to write the debug information and activate
debug. Debug information can be written to either a Java console window, or a log file. Instructions for writing to the
console or a log file and activating debug follow.
Writing to the Java Console
To write client debug to the Java console window:
1. Open the Windows Control Panel on the client machine.
2. From the Control Panel, select the Java.
This will open the Java Control Panel window.
3. From the Java Control Panel window, select the Advanced tab.
4. On the Advanced tab, select the Show console radio button under the Java Console group.
5. Repeat the above steps on each client machine you want to view a Java console for.
You have now specified the Java console as the place to write client debug information. Now you must
activate client debug in Applications Manager. Debug for the servers and clients can be turned on or off in the
Options.properties file by selecting true or false for the Debug option. There is a difference between turning on
client debug in the Applications Manager client vs. the Options.properties file. When you turn client debug on from
the Applications Manager client, it only shows debug for the current session (in other words, what's going on right
now in the client). When you turn it on in Options.properties, you see all of the information the client first loads
on start-up. If you need to see startup information, turn on debug in the Options.properties file, not the client. To
activate client debug for all Applications Manager Users, do the following:
1. In the Options.properties file, set Debug to true as shown below:

Debug=true

The location for the Options.properties file is:

 Applications Manager 9.4.1

UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

2. After making any changes to the Options.properties file, you must stop and restart the RMI process going to
the site directory and issuing the following commands:
For UNIX:

. sosite
stopso rmi
startso rmi

For Windows:

sosite
stopso rmi
startso rmi

Now the output is written to the Java Console. To turn debug off when you finish troubleshooting, deselect the
Show console option on the Java Control Panel window, set Debug to false in Options.properties, and stop
and restart the RMI process.
When client debug is activated from the About Applications Manager window, it overrides the
Options.properties setting.
Writing to a Log File
To write client debug information to a log file:
1. Open the Windows Control Panel on the client machine.
2. From the Control Panel, select the Java.
This will open the Java Control Panel window.
3. From the Java Control Panel window, select the Advanced tab.
4. On the Advanced tab, select the Enable tracking checkbox under the Debugging group.
You have now enabled Java trace. Now you must activate client debug in Applications Manager. To activate client
debug, do the following:
1. From the Applications Manager client, open the About Applications Manager window by selecting About
Applications Manager from the Help menu.
2. Check the Client box under the Debug menu on the About Applications Manager window.
The trace files are written to the following directory where <OS user name> is your OS user name:

C:\Users\<OS user name>\AppData\LocalLow\Sun\Java\Deployment\log

 Applications Manager 9.4.1

To turn debug off when you finish troubleshooting, simply uncheck the Debug setting on the About Applications
Manager window.
Writing to a Log File
To write client debug information to a log file:
1. Navigate to and edit the following file, where <OS user name> is your OS user name:

C:\Users\<OS user name>\AppData\LocalLow\Sun\Java\Deployment\deployment.properties

2. Add the following line to the deployment.properties file:

deployment.javaws.traceFileName=c\:\\AM\\java.log

3. In the Options.properties file, set Debug to true as shown below:

Debug=true

The location for the Options.properties file is:

UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

4. After making any changes to the Options.properties file, you must stop and restart the RMI process going to
the site directory and issuing the following commands:
For UNIX:

. sosite
stopso rmi
startso rmi

For Windows:

sosite
stopso rmi
startso rmi

Now the output is written to the file. When new output is written, it is appended to the existing file which does not
roll over. Therefore, you should create a new file to isolate current data. If you cannot delete the existing file, you
can edit the file, delete its contents and save it.
 Applications Manager 9.4.1

To turn debug off when you finish troubleshooting, remove the line you added to the deployment.properties file,
set Debug to false in Options.properties, and stop and restart the RMI process. When client debug is activated
from the About Applications Manager window, it overrides the Options.properties setting.

Setting Server Debug

Debug for the RmiServer and AgentService processes can be turned on by selecting Server from the Debug menu
on the About Applications Manager window or in the awenv.ini file by selecting true or false for the Debug
option.
There is a difference between turning on server debug in the Applications Manager client vs. the awenv.ini file.
When you turn RMI debug on from the Applications Manager client, it only shows server debug for the current
session (in other words, what's going on right now in the client and the Automation Engine). When you turn it on in
awenv.ini, you see all of the information the RmiServer and AgentService processes first load on start-up. This
includes the virtual day, predecessor information, and Automation Engine and RMI settings.
This startup information isn't loaded again unless the RMI is restarted, so it won't appear in debug if turned on from
the client. If you need to see startup information, turn on debug in the awenv.ini file, not the client.
Setting RMI Server Debug for the Current Session
To turn set RMI server debug for the current session, check the Server box under the Debug menu on the About
Applications Manager window.
The debug information is written to the RmiServer.<timestamp>.log file.
To turn off debug, uncheck the Server box under the Debug menu on the About Applications Manager window.
Setting Server Debug to Include Start-up Information
To set debug to include start-up information, add a debug=true section under the [default] section in the awenv.ini
file in the Applications Managersite directory as shown in the example below.

[default]
Debug=true

Debug information is written to the RmiServer.log at startup, and stops once the bind to the RMI port is finished.
The debug stream then switches to the RmiServer.<timestamp>.log file. The RmiServer log with the timestamp
then records setup information. After startup, only exceptions are written to RmiServer.log.
To turn debug off when you finish troubleshooting, set Debug to false in the awenv.ini file as shown in the example
below.

[default]
Debug=false

When server debug is activated from the About Applications Manager window, it overrides the awenv.ini setting.
Enabling/Disabling RMI Server Debug with the RMI_DEBUG Job
You can enable or disable RMI server debug by running the RMI_DEBUG Job shown in the Submit window below.
Like all Applications Manager Jobs, you can request and submit RMI_DEBUG to run it ad hoc, or schedule it.
Activate or deactivate RMI server debug by setting the Enable prompt to Yes or No.
 Applications Manager 9.4.1

Importing the RMI_DEBUG Job

To bring the RMI_DEBUG Job into Applications Manager, You must run an Applications Manager import by doing
the following:
1. Select Import from the Activities menu on the Applications Manager desktop to open the Import window.
2. From the File menu on the Import window, choose Open Import File.
Applications Manager displays the Import Files window.
3. Choose import file RMI_DEBUG from the list and click OK.
A list of mappable objects appears in the Import window. You should not have to re-map any of these objects.
4. To start the import, click Import.
5. Open the Explorer window and check that the IMPORT task is running. It will return a FINISHED status when
complete.
The Automation Engine and Agent must be running for the IMPORT task to run.
For more information on running imports, see the Development Guide.
Setting Server Debug with an awexe Call
RmiServer and AgentService processes debug can be turned on from the command line or in a script using
the awexe SCHEDULE_DEBUG command. It allows you to specify a start time in 24-hour format and number of
minutes to keep debug on. The syntax for the arguments is shown below:

awexe SCHEDULE_DEBUG START_TIME=<HH:mm> MINUTES=<mmm>

Setting Printem Debug

Printem debug is now controlled by adding a printemDebug line to the awenv.ini file.

Setting Oracle Trace

If you want to see what SQL is executed by the RmiServer process, you can turn on Oracle trace.
 Applications Manager 9.4.1

Normally you shouldn't need to turn on general SQL trace for the whole product, because you can determine which
SQL statements or procedures are having problems and trace only those statements or procedures. For example, if
the problem is the SQL in one task, you can add this line to the beginning of that task's script:

alter session set sql_trace=true;

To set Oracle trace, check the SQL box under the Debug menu on the About Applications Manager window.
Debug information will be written to the trace files in the $ORACLE_HOME/rdbms/log directory.
You have to log in to the client to toggle the SQL debugging for Oracle-it won't be available if you get to the About
Applications Manager window from the Login screen.
To turn off Oracle trace, uncheck the SQL box under the Debug menu on the About Applications Manager
window.

Setting startso Debug in UNIX

Use the following steps to capture startso debug into a UNIX file:
1. Stop all Applications Manager processes and verify all processes were stopped. On UNIX you can use a
command like this to check if everything is stopped:

> ps -ef|grep $AW_HOME

startso rmi >$AW_HOME/log/startso_rmi.log 2>&1

2. Create a 0-byte file named startso in the $AW_HOME/debugdirectory. If you don't have a debug directory,
create one.
3. Issue the commands below that are appropriate for your situation (wait for them to return to the command
prompt):

startso >$AW_HOME/log/startso.log 2>&1

4. Check the $AW_HOME/log/startso*.log file and send to support if necessary.

To turn off debug, delete the $AW_HOME/debug/startso file.

Debugging the awcomm and awnetex C Processes

You can get more detailed logs for the awcomm and awnetex C processes by adding the line debug_mask=T|
ALL|L4 in the awenv.ini file.
Setting debug masks for C processes was common practice in previous Applications Manager versions; today it is
rarely required.
Activating Debug for the awcomm and awnetex C Processes
If you need to turn on debug for the awcomm and awnetex C processes, on an Automation Engine or a Remote
Agent, add the debug_mask=T|ALL|L4 line under the [default] section in the awenv.ini file in the Applications
Managersite directory. An example is shown below.

[default]
debug_mask=T|ALL|L4

It is not necessary to restart of the Applications Manager processes after editing the awenv.ini file.
Optionally Setting Up Debug Rollover
 Applications Manager 9.4.1

Debug files are started by default every 24 hours. To create more manageable debug files, you can set your debug
files to rollover more often by adding the rollover_interval setting in the [default] section of the awenv.ini file. The
rollover_interval setting is based on a number of minutes as shown below:

[default]
rollover_interval=120
debug_mask=T|ALL|L4

Once you start writing to a new debug file, you can edit, remove, or compress the old file.
Recreating the Problem and Sending Files to Support
After you set debug for an Applications Manager process, try to recreate the problem that you are troubleshooting.
When you see the problem appear again, go immediately to the Applications Manager log directory and look for the
files with a .debug extension. They are the files created by the debug utility for processes. They are also the files
most frequently requested by Broadcom Support.
We recommend that you zip your .debug files before sending them to Broadcom Support.
Warning: When the debug utilities are activated, log files can balloon in size. You should activate debug
only when you are troubleshooting, then deactivate it when you are done troubleshooting. If you leave
debug active, you may run out of disk space.
Deactivating Debug for the awcomm and awnetex C Processes
After the problem or error is captured, remove the text to the right of the debug_mask= line in the [default] section
of the awenv.ini file as shown below:

[default]
debug_mask=

Copying and Moving Applications Manager Instances

Circumstances may require you to copy or move a Applications Manager instance. This chapter provides
instructions for the most common scenarios: copying an instance, moving an instance, moving only the
Applications Manager Automation Engine, and moving only the Applications Manager database.
There are many reasons why you may want to move or copy an Applications Manager instance:
• You want to move Applications Manager from a development environment to a test environment.
• The current Applications Manager server is being expired.
• You want to create a fail-over copy on a backup server.
• You want to expand the number of Automation Engines.
This chapter covers the following scenarios:
• Copying or moving an Applications Manager Automation Engine and database to the same machine or a
different machine.
• Moving an Applications Manager Automation Engine to another machine.
• Moving an Applications Manager database to another machine.
These are the scenarios that customers deal with most frequently. The scenarios are illustrated below.
 Applications Manager 9.4.1

Oracle Export vs. Applications Manager Export

The procedures described in this chapter rely on the Oracle export utility rather than the Applications Manager
export utility. By using the Oracle export, you ensure that all Applications Manager objects are copied or moved to
the new instance. The assumption is that the exported data will replace any and all data in the target database.
The Applications Manager export utility is designed to move selected items from one Applications Manager
instance to another without altering the existing data in the target database. For example, you may have created
several new Jobs and a new Process Flow in a development environment, and you want to copy them to a test
environment.
New vs. Existing Machines
The procedures above refer to new and existing machines. A new machine is one where Applications Manager
has never been installed. An existing machine is one where one or more instances of Applications Manager have
already been installed.
Different procedures exist for new and existing machines because on a new machine, you want to install
Applications Manager first to make sure it runs correctly on that machine. After verifying that Applications Manager
runs on the machine, then you want to copy or move the Automation Engine and/or database to that instance.
On a machine that already has one or more instances of Applications Manager running, you can use a more
streamlined copying and moving procedure.

Before You Begin

Before performing any of the tasks described in this chapter, you must:
• Stop the Automation Engine and Agent.
• Clear all tasks from the Backlog from the Explorer window.
• Stop all Applications Manager related processes.
These procedures only apply to Oracle users copying and moving between identical operating systems.
Naming Recommendations
We recommend using unique Agent names for each instance of Applications Manager regardless of host. The
same Database Login name can be used in separate database instances.
 Applications Manager 9.4.1

Key Words
The following key words are used in the procedures presented in this chapter.
• Source: Refers to the existing Applications Manager instance (the one you want to copy or move).
• Target: Refers to the instance you will be creating.
• Copy: Implies that the source is NOT deleted. You will need to change the new Agent name and Database
Login if the accounts reside in the same database instance.
• Move: Implies that the original source will be deleted after copying files to a new target account. Changing the
Agent and Database Login names is not required.
Manual Control
The procedures described in this chapter for copying, moving, and renaming your Applications Manager instances
use the Applications Manager installation program. If you have customized settings within your Applications
Manager files, you can manually alter many of the files Applications Manager recreates within these procedures.

Three-tiered Methodology
The Applications Manager application-centric philosophy ensures that development, testing, and production occur
simultaneously while minimizing downtime to your mission-critical production instance. The Applications Manager
three-tiered methodology, when used effectively, ensures that modifications and enhancements occur quickly and
safely in your application environment.
IT personnel realize the importance of compartmentalizing development, testing, and production environments.
The key mission of all database applications is to get them up and running and keep them running. Yet in attaining
this goal, IT departments must contend with constantly changing requirements and requests to improve database
performance, flexibility, and functionality. IT departments, which must keep enterprise applications running 24/7,
need a solution that ensures modifications and enhancements occur quickly and safely in their production instance.
The Applications Manager three-tiered methodology provides this solution.

Although this methodology (as shown above) may appear obvious, this is often not the case for many
organizations. The three-tiered approach encourages organizations to maintain separate development, testing, and
production instances. The advantages of this approach are many:
• Separating production from development and testing decreases the chance of an untested program going awry
and tying up mission-critical resources and personnel.
• Most decisions can be made 'up front' with already established requirements and goals.
• All applications are managed to a single design standard. Cross-platform, cross-application, and cross-phase
conflicts are avoided since any change made in one instance can be passed onto another.
In other words, no matter where you are, you can anticipate and develop your specific components independently
and in advance of other components. Many organizations take a system-level approach, where each database
instance is administered independently. Incompatibilities arise when developers design for one instance only to
discover that the production instance was modified to accommodate the request of yet another developer. Since
each phase is 'blind' to each other, decisions in one instance can directly conflict with requirements in another
instance.
Applications Manager addresses these concerns through its application-centric, three-tiered design philosophy.
Export and Import windows make this happen.
Definitions and Terms

Term Description

Developer Refers to database developer. Responsible for creating

new Jobs and programs.

QA/Testing Refers to quality assurance personnel. Responsible for

testing new Jobs or diagnosing existing Jobs.
 Applications Manager 9.4.1

Term Description

Sys. Admin. Refers to system or database administrator.

Responsible for maintaining and implementing QA and
production databases with Jobs and programs supplied
by the developer.

Applications Manager Instance The location of the Applications Manager repository.

It is possible for Applications Manager to reside in
one location, but run tasks on one or more remote
databases.

Source Refers to your existing instance of Applications

Manager-the one with objects you want to move.

Target Refers to the new instance you created-the one you

want to receive objects.

Design Structure for Three-tiered Implementation

The ideal configuration for an enterprise system would contain three Applications Manager instances. These
instances can share one database, have individual databases, or a combination.
Most organizations will begin with a development instance. When initial development nears completion, an Oracle
export of the development database occurs. This new export becomes the QA/Testing instance. Following QA,
another export is performed resulting in the creation of the production instance. Ideally your QA instance should
mirror your production instance.
Frequently, the development and QA instances point to the same Library paths while the Production Libraries point
to the production directories. There are two methods to separate the development, QA, and production Database
Logins:
• The primary way is to use the same Database Login names in different instances and with different passwords
(to preclude accidental updates of the wrong database). This method allows the same dynamic Substitution
Variables to be used in all three instances. If any Database Logins require SQL*Net connect strings, then a local
tnsnames.ora file must be created for each instance.
• The alternative method is to use different Database Logins in each instance and use Applications Manager
Mapping to adjust the imports. One drawback is that each instance must have unique dynamic Substitution
Variables if they contain remote database references.
Broadcom Support has procedures for moving an Applications Manager Automation Engine (Oracle database)
from one machine to another like machine. Oracle's export utility performs a full export of the source instance's
Oracle account, which exports everything-all data and objects. It produces a .dmp file, which is moved to the target
database's home directory.
Following the initial Oracle exports and imports, you use the Export and Import windows to transfer Applications
Manager objects without having to revamp or recreate entirely new instances for minor updates. The image below
clarifies the differences between the Oracle and Applications Manager exports/imports.
 Applications Manager 9.4.1

Notice that the arrows are bi-directional for Applications Manager. This is because it is possible, and in fact likely,
that Applications Manager objects will be transferred between different instances. For example, if a production
Process Flow has been modified in the production instance and produces an error, the Process Flow can be
duplicated in the QA instance for additional testing.
The Oracle Export/Import utility handles bulk transfers of an entire database. Applications Manager is much more
'surgical,' allowing administrators to pick and choose individual objects for export.
A typical scenario for organizations running enterprise applications may look like this:
1. Create two additional instances of currently existing database (enterprise).
2. Install Applications Manager development, testing, and production instances on each of the mirrored
applications.
3. Develop new objects and application in the development instance.
4. Export the objects.
5. Import the objects into the testing instance. If the objects fail testing, allow Development to make changes and
resubmit the objects. If the objects pass testing, import the objects into the production instance.
The location of the various Applications Manager instances is irrelevant when using the Applications
ManagerExport and Import windows. The export utility creates a flat file that can be copied or sent via FTP to the
import directory of any Applications Manager instance.

Stopping and Starting Applications Manager Processes

Before performing any copy or move procedure, we recommend that you stop all Applications Manager processes.
The procedure for stopping and starting Applications Manager UNIX and Windows processes have been included
here for your convenience.
UNIX Processes
To stop all Applications Manager UNIX processes:
1. To stop all Applications Manager Agent processes, including any Remote Agent processes, and make sure no
tasks are running, issue the following command.

stopso agent all

stopso awcomm

2. To stop all the Applications Manager processes, issue the following commands:

stopso

Windows Processes
To stop all Applications Manager Windows processes:
1. Make sure no tasks are running.
2. For the instances, stop all Applications Manager processes, including any Remote Agent processes, by
selecting Start>Programs>Applications Manager>Stop Applications Manager Processes><Agentname>.
3. Stop the awcomm process from the Windows Task Manager.
4. Stop the WatchWorx service by opening the Services applet from the Windows Control Panel, selecting the
WatchWorx service AWW-<Agentname>, and clicking Stop.
Starting Applications Manager Windows Processes
To start the Applications Manager Windows processes:
1. To start the WatchWorx service, go to the Control Panel Services applet, select the WatchWorx service, and
click Start. This will automatically launch the aw processes.
2. Start your Automation Engine and Agent processes from the Explorer window.
 Applications Manager 9.4.1

Copying or Moving an Automation Engine/Database to a New Machine

This topic describes how to copy or move an Applications Manager Automation Engine and database to a new
machine running on the same platform. For example, you can move the Automation Engine between different
versions of UNIX, or different versions of Windows. This procedure is not for moving an Automation Engine from a
UNIX system to a Windows system. The key steps in the procedure are:
1. Install Applications Manager on the target machine
2. Import the data to the target machine
3. Run the SQL updates
4. Copy the Applications Manager support files to the target instance
5. Copy the Applications Manager support files to the target instance
Each step is described in detail in the procedures below. To complete this procedure, you will need the Applications
Manager Oracle user login and password, and the sys account user login and password.
Install Applications Manager on the target machine
To install Applications Manager on the target machine:
1. Create the Applications Manager UNIX or Windows user on the target system.
The user can be the same on both systems. For details, see the Installation Guide.
2. Create the Applications Manager Oracle user on the target system.
The user can be the same on both systems. For details, see the Installation Guide.
3. Install Applications Manager on the target system.
Make sure the Applications Manager version is the same for the source and target machines.
4. Test the system to make sure Applications Manager is working correctly.
5. Stop all Applications Manager processes.
Import the data to the target machine
To move the data to the target machine:
1. On the source system, perform an Oracle export of the Applications Manager user.
Using the Oracle export utility (EXP), perform a full user export of the source instance's Oracle account. Export
everything-all data and objects. Move the resulting .DMP file to the target's home directory.
2. On the target system, import the Oracle export.
Using the Oracle import utility (IMP), perform a full user import of the .DMP file into the target instance's Oracle
account. Import everything-all data and objects.
Run the SQL updates
After importing the data on the target system, you must check the Automation Engine's name, IP address, and login
information to make sure they are correct.
1. Log into SQL*Plus as the Applications Manager Oracle user on the target machine.
2. Reset the database privileges by logging into SQL*Plus as the Applications Manager user and run sysdba.sql
in the sql directory.
You will need the sys account password to execute this step.
Rerun the installation procedure
After importing the data and running the SQL updates, you need to rerun the database portion of the Applications
Manager installation to verify all objects in the database.
UNIX
To rerun the database portion of the Applications Manager installation:
1. Log into UNIX as the Applications Manager user, switch to the site directory, issue the . sosite command.
2. Switch back to the Applications Manager home directory and issue the awinstall command.
3. When prompted, select option 1: Initial Install/Upgrade from Prior Version.
4. Follow the onscreen prompts.
 Applications Manager 9.4.1

5. If the values in your data do not match, you will receive a prompt similar to the following:

****Automation engine IP, user name, Oracle id - Do not match****

The old and new values will be listed. Verify the changes are correct.. Enter 'Y' at the prompt shown below and
the install will update the values in the database:

Change database to new values [N]?

Windows
To rerun the database portion of the Applications Manager installation:
1. Open a command prompt, switch to the site directory, and issue the sosite command.
2. Switch back to the Applications Manager home directory and issue the awinstall command.
3. When prompted, select option 1: Initial Install/Upgrade from Prior Version.
4. Follow the onscreen prompts.
5. If the values in your data do not match, you will receive a prompt similar to the following:

****Automation engine IP, user name, Oracle id - Do not match****

The old and new values will be listed. Verify the changes are correct.. Enter 'Y' at the prompt shown below and
the install will update the values in the database:

Change database to new values [N]?

Copy the Applications Manager support files to the target instance

Copy any scripts (i.e.: program files, run-time extension scripts) that were defined on the source instance to the
target instance.

Copying or Moving an Automation Engine/Database to an Existing Machine

This topic describes how to copy or move an Applications Manager Automation Engine and database to the same
machine or to an existing machine where Applications Manager has been installed previously. The key steps in the
procedure are:
1. Create the Applications Manager Oracle user
2. Import the data to the target machine
3. Run the SQL updates
4. Run the Applications Manager installation procedure
5. Copy the Applications Manager support files to the target instance
Each step is described in detail in the procedures below.
Create the Applications Manager Oracle user
The first step is to create the Applications Manager Oracle user. This database will be used for the Applications
Manager installation.
To create an Oracle account for Applications Manager:
 Applications Manager 9.4.1

1. Log into the database where you will be creating the Oracle account for Applications Manager and issue the
following command:

grant connect, resource to <am> identified by <password>;

alter user <am> temporary tablespace <tmpspace>;

2. To give the Applications Manager account the privileges required to create tables, views, indexes, procedures,
triggers and sequences, issue the following commands:

alter user <am> default tablespace <tspace>;

In the commands above, replace <am>, <tspace>, and <tmpspace> with appropriate values for your system.
Warning: If you do not set the default and temporary tablespaces for the Applications
Manager account, all the Applications Manager database objects will be created in the system
tablespace.
3. To prevent the Applications Manager installation script from prompting for the Oracle sys password, you
can grant the appropriate privilege to a system table ahead of time. Make the following grants from the
Oracle sys account:

grant select on SYS.V_$SESSION to <am>;

grant select on SYS.V_$LOCK to <am>;
grant execute on dbms_pipe to <am>;
grant execute on dbms_lock to <am>;
grant execute on dbms_output to <am>;
grant create view to <am>;
grant create procedure to <am>;
grant create trigger to <am>;
grant create database link to <am>;

If you have multiple Automation Engines running in the same database, and you try installing a new Automation
Engine in the same database, you may have trouble granting access to dbms_pipe. If you have trouble, try
stopping the other Automation Engines.
Import the data to the target machine
To move the data to the target machine:
1. On the source system, perform an Oracle export of the Applications Manager user.
Using the Oracle export utility (EXP), perform a full user export of the source instance's Oracle account. Export
everything-all data and objects. Move the resulting .DMP file to the target's home directory.
2. On the target system, import the Oracle export.
Using the Oracle import utility (IMP), perform a full user import of the .DMP file into the target instance's Oracle
account. Import everything-all data and objects.
Run the SQL updates
After importing the data to the target system, you must check the Automation Engine's name, IP address, and login
information to make sure they are correct.
1. Log into SQL*Plus as the Applications Manager Oracle user on the target machine.
2. Reset the database privileges by doing the following:
1.1 Copy the sysdba.sql in the sql directory on the source machine to the sql directory on the target machine.
2.1 Log into SQL*Plus as the Applications Manager user and run sysdba.sql.
 Applications Manager 9.4.1

You will need the sys account password to execute this step.
Run the Applications Manager installation procedure
After importing the data and running the SQL updates, you need to run the Applications Manager installation.
UNIX
To run the Applications Manager installation:
1. Log into UNIX as the Applications Manager user, switch to the Applications Manager home directory, and run
the CDINST.SH program.
2. When prompted, select option 1: Initial Install/Upgrade from Prior Version.
3. Follow the onscreen prompts.
4. If the values in your data do not match, you will receive a prompt similar to the following:

****Automation engine IP, user name, Oracle id - Do not match****

The old and new values will be listed. Verify the changes are correct.. Enter 'Y' at the prompt shown below and
the install will update the values in the database:

Change database to new values [N]?

Windows
To run the Applications Manager installation:
1. Run the installation executable
If you are installing from a CD, use cdinstall.bat. If not, then open a command prompt, go to the site directory,
call sosite.bat, then awinstall.
2. When prompted, select option 1: Initial Install/Upgrade from Prior Version.
3. When prompted to select an Automation Engine/Agent upgrade, select 'Automation Engine OTHER'.
4. Follow the onscreen prompts.
5. If the values in your data do not match, you will receive a prompt similar to the following:

****Automation Engine IP, user name, Oracle id - Do not match****

The old and new values will be listed. Verify the changes are correct. Enter 'Y' at the prompt shown below and
the install will update the values in the database:

Change database to new values [N]?

Copy the Applications Manager support files to the target instance

Copy any scripts (i.e.: program files, run-time extension scripts) that were defined on the source instance to the
target instance.

Copying or Moving an Automation Engine to a New Machine

This topic describes how to copy or move an Applications Manager Automation Engine to a new machine running
on the same platform. For example, you can move the Automation Engine between different versions of UNIX, or
different versions of Windows. This procedure is not for moving an Automation Engine from a UNIX system to a
Windows system. The key steps in the procedure are:
1. Configure the database for the Automation Engine on the new machine
 Applications Manager 9.4.1

2. Run the installation

3. Copy the Applications Manager support files
4. Optionally, delete the source Automation Engine
Configure the database for the Automation Engine on the new machine
To configure the database for the Automation Engine on the new machine:
1. Stop all Applications Manager processes on the source system.
For information on stopping the Applications Manager processes, see Stopping and Starting Applications
Manager Processes.
2. Check connectivity to the database from the target machine by issuing one of the following commands on the
target machine:

sqlplus <user>/<password>
sqlplus <user>/<password>@<connect string>
truncate table so_users_log;
truncate table so_job_history;
commit;

Run the installation

Run the appropriate Applications Manager installation as described below.
UNIX
To run the Applications Manager installation:
1. Log into UNIX as the Applications Manager user, switch to the Applications Manager home directory, and run
the CDINST.SH program.
2. When prompted, select option 1: Initial Install/Upgrade from Prior Version.
3. Follow the onscreen prompts.
4. If the values in your data do not match, you will receive a prompt similar to the following:

****Automation engine IP, user name, Oracle id - Do not match****

The old and new values will be listed. Verify the changes are correct.. Enter 'Y' at the prompt shown below and
the install will update the values in the database:

Change database to new values [N]?

Windows
To run the Applications Manager installation:
1. Run the installation executable
If you are installing from a CD, use cdinstall.bat. If not, then open a command prompt, go to the site directory,
call sosite.bat, then awinstall.
2. When prompted, select option 1: Initial Install/Upgrade from Prior Version.
3. When prompted to select an Automation Engine/Agent upgrade, select 'Automation Engine OTHER'.
4. Follow the onscreen prompts.
5. If the values in your data do not match, you will receive a prompt similar to the following:

****Automation engine IP, user name, Oracle id - Do not match****

 Applications Manager 9.4.1

The old and new values will be listed. Verify the changes are correct.. Enter 'Y' at the prompt shown below and
the install will update the values in the database:

Change database to new values [N]?

Copy the Applications Manager support files

Copy any scripts (i.e. program files, run time extension scripts, etc.) that were defined on the source machine to the
target machine.
Optionally, delete the source Automation Engine
If you are copying the Automation Engine, then leave the source Automation Engine in place. If you are moving the
Automation Engine, then delete the source Automation Engine.
To delete the Applications Manager instance in a UNIX environment:
1. Stop all Applications Manager processes.
2. Remove the Applications Manager directory on the source instance.
To delete the Applications Manager instance in a Windows environment:
1. Stop all Applications Manager processes including awcomm and the WatchWorx service.
2. Remove the WatchWorx service:

%AW_HOME%\site\sosite.bat
instsrv -remove AWW-<Agent name>

3. Remove the Applications Manager directory on the source.

Copying or Moving an Applications Manager Database

Follow the steps outlined in this topic to successfully copy or move an Applications Manager database for UNIX or
Windows.
The key steps in copying or moving an Applications Manager database are:
1. Export the source instance and import the data into the target database.
2. Run the installation.
Each step is described in detail in the procedure below.
Procedure
To copy or move the Applications Manager database:
1. Export the source instance.
Using the Oracle export utility (EXP), perform a full User export of the source instance's Oracle account. Export
everything-all data and objects. Move the resulting .DMP file to the target's home directory.
2. Have your DBA drop (cascade) the target database account to ensure that the database is empty.
3. Recreate the target database account using the same user name and password that it had before. The target
account will now be empty.

grant connect, resource to <target> identified by <target_password>;

alter user <user name> <target> default tablespace <am_tablespace>;
USER
------------------------------
AM
granting select on some sys tables/views to AM
Enter value for enter_sys_password: change_on_install
 Applications Manager 9.4.1

Connected.
old 1: grant select on v_$session to &login with grant option
new 1: grant select on v_$session to AM with grant option
Grant succeeded.

4. Using the Oracle import utility (IMP), perform a full user import of the source instance's .DMP file into the target
database account. Import everything-all data and objects.
5. Recreate the target database account's sys grants by logging into SQL Plus as the target Applications Manager
Oracle user ID and running the sysdba.sql script located in the sql subdirectory in the AW_HOME directory.
You will be prompted for the Oracle sys password.

SQL>@sys

6. Reconcile the target sosite file by adding environment variables from the source sosite file.
7. Run the appropriate Applications Manager installation as described below.
UNIX
To run the Applications Manager installation:
1.1 Switch to the site directory and run .sosite.
2.1 From the Applications Manager home directory, run the awinstall program.
3.1 When prompted, select option 1: 'Initial Install/Upgrade from Prior Version'.
The install will list the current values (i.e.: Automation Engine name, IP address, Oracle ID.) and display the
following prompt:

Is the above information correct [Yes]?

4.1 If the above information is correct, go to step 7f below. If you changed the connect string, Database Login,
database IP, or database password, you must answer 'No' to the prompt.
5.1 Enter each new value, pressing the Enter key to go to the next value.
After you enter the last value, Applications Manager will check the values against the database. If the
values in your database do not match the new values you entered above, you will receive a prompt similar
to the following:

****Automation engine, IP, User Name, Oracle ID - Do not match****

The old and new values will be listed.

6.1 Verify the changes are correct.
If the values are correct, enter 'Y' at the prompt shown below and the install will update the values in the
database:

Change database to new values [N]?

If the values are incorrect, enter 'N'. Applications Manager will exit the install. You can then rerun the install
and enter the correct values.
7.1 Follow the onscreen prompts.
Windows
To run the Applications Manager installation:
 Applications Manager 9.4.1

1.1 Open a command prompt, switch to the site directory, and run sosite.
2.1 From the Applications Manager home directory, run awinstall.
3.1 When prompted, select option 1: 'Initial Install/Upgrade from Prior Version'.
The install will list the current values (i.e.: Automation Engine name, IP address, Oracle ID.) and display the
following prompt:

Is the above information correct [Yes]?

4.1 If the above information is correct, go to step 7f below. If you changed the connect string, Database Login,
database IP, or database password, you must answer 'No' to the prompt.
5.1 Enter each new value, pressing the Enter key to go to the next value.
After you enter the last value, Applications Manager will check the values against the database. If the
values in your database do not match the new values you entered above, you will receive a prompt similar
to the following:

****Automation engine, IP, User Name, Oracle ID - Do not match****

The old and new values will be listed.

6.1 Verify the changes are correct. If the values are correct, enter 'Y' at the prompt shown below and the install
will update the values in the database:

Change database to new values [N]?

If the values are incorrect, enter 'N'. Applications Manager will exit the install. You can then rerun the install
and enter the correct values.
7.1 Follow the onscreen prompts.
8. If you are copying the instance, then leave the source instance in place. If you are moving the instance, then
delete the source database user.
To delete the source database user:
1.1 Remove the database user pipe by logging into SQL*Plus as the Applications Manager database user and
issuing the following commands:

declare
ret number;
begin
dbms_pipe.purge(<user name>||'pipe_master');
ret:=dbms_pipe.remove_pipe(<user name>||'pipe_master');
end;

Where <user name> is the name of the Oracle user and is not SYS or SYSTEM.
2.1 Drop the Applications Manager Oracle user by logging into SQL*Plus as sys and issuing the following
command:

drop user <user name> cascade;

 Applications Manager 9.4.1

Host and Client Customization

As a Applications Manager administrator, you may want to customize Applications Manager. To customize
Applications Manager, you change variables set in one of several places. Host/background changes are set in the
following files:
• sosite
• awenv.ini
Client changes are set in the following Java files:
• Masters.properties
• Options.properties
sosite File
Variables in the sosite file control the Applications Manager Background Manager and WatchWorx. The sosite file
is located in the site directory. For more information, see Background Manager and WatchWorx Variables.
awenv.ini File
The awenv.ini file is located in the site subdirectory and is the environment initialization file. For more information,
see awenv.ini Environment Initialization File.
Options.properties File
The Options.properties file controls many of the client behaviors. For more information, see Options.properties
File.
Masters.properties File
The Masters.properties file contains Automation Engine names for the Applications Manager Automation Engine
or Automation Engines. For more information, see Masters.properties File.

Background Manager and WatchWorx Variables

The sosite file includes variables that control the Applications Manager Background Manager and WatchWorx.
The sosite file is located in the site directory under AW_HOME.
Background Manager Variables
The following environment variables control the Applications Manager Background Manager functions.

Variable/Syntax Description

DURING_WAIT By default, Applications Manager evaluates conditions

once every 60 seconds. This variable will evaluate
=<no. of seconds>
DURING conditions at longer length intervals. Minimum
value is 60.

JOB_START_LIMIT The maximum number of tasks that can be started in

one Queue before Applications Manager will launch
=<no. of tasks>
tasks in another Queue. Set to 10 tasks by default. This
variable ensures that load balancing occurs equally on
Queues with equal priorities.

WatchWorx Variables
WatchWorx is an Applications Manager program that monitors the Automation Engine's processes and restarts
them if they go down. The following environment variables are used with WatchWorx.

Variable/Syntax Description

factor=<n> If not assigned, Applications Manager default behavior

= ' '.

max_cycles=<n> If not assigned, Applications Manager default behavior

= '3.'
 Applications Manager 9.4.1

Variable/Syntax Description

max_time_reboot=<n> If not assigned, Applications Manager default behavior

= '1800' seconds (30 minutes).

min_time_reboot=<n> If not assigned, Applications Manager default behavior

= '120' seconds.

watchworx=<no> If this environment variable is set, it prevents the

WatchWorx process from starting when the Automation
Engine starts.

WatchWorx_max_idle=<n> This value is used when checking processes. If a

process has a status other than Online for more than
<n> seconds, WatchWorx will attempt to restart the
process.
If left blank, the WatchWorx default value = '300'
seconds.

Executing your Environment in UNIX and Windows

Whenever you change the sosite file, you must run the sosite script for the changes to take effect. You can
manually update the Applications Manager environment by switching to the site directory and typing . sosite for
UNIX or sosite for Windows.

awenv.ini Environment Initialization File

The awenv.ini environment initialization file is located in the site directory. Applications Manager reads this file
when each program starts and when a change is made to the file. The last change time for the file is checked each
pass through the main loop in the C programs and the file is reread if it changed. This allows you to turn debug on
and off by updating the file. A sample awenv.ini file for UNIX is shown below.

[default]
AGENT=PROD71
MASTER=PROD71
MASTER_IP_ADDRESS=222.3.4.21
DB_SID=804
DB_IP=222.3.3.64
TZ=America/Los_Angeles
RMI=Yes
debug=true
UseNetworkTime=true
[awoae]

Replacement Substitution Variables

You can use replacement Substitution Variables in the awenv.ini file. For example, you can use AW_HOME in
a path. For a list of valid Replacement Values, see awenv.ini Replacement Values and Variables. If you use a
variable, you must enclose it in { } brackets.
Log and Error Files
The log and error files are stored in the log subdirectory under AW_HOME. Log files have a .log extension.
STDERR and error messages have a .err extension. The format for the file names is:

<program>.<pid>.log
 Applications Manager 9.4.1

<program>.<pid>.err

The log and error files are created by default. If a debug mask is defined (see below), a .debug file is also created.
Debug Masks
A debug mask controls the amount of detail written to the .debug log file. The syntax for the debug mask is:

Debug_mask=T|INI|NET|DB|PRT|UTIL|ALL|L1

The debug mask options are described below

Option Description

T= Trace (also written as TRC). Makes entry/exit messages

show.

INI = Initialization

NET = Network

DB = Database

PRT = Printer (used with AgentService)

UTIL = Utility

RUN = General running (used with AgentService)

GEN = General (used with AgentService)

TAG = Includes these debug mask variable tags.

CON = Conditions

CKF = Check file

NOTIME = Do not include timestamp in debug log.

WRI = Create a new debug file whenever the awenv.ini file is

saved.

TRN = Translate

BUF = Have Applications Manager write data in large buffers

(for example, across data pipes or sockets) to the
debug log. To use this setting you would probably
need to turn encryption off. For information on turning
encryption off, contact Broadcom Support.

ALL = All of the above except T and BUF.

L1 - L4 = Level of detail. Level 1 includes transaction processes

and high level information. Each subsequent level
includes more detail. If the level is not specified, level 1
is shown.

For more information on DEBUG masks, see Debugging the awcomm and awnetex C Processes.
 Applications Manager 9.4.1

awenv.ini Replacement Values and Variables

Replacement Values allowed and common variables used in the awenv.ini file are described below.
Replacement Values
Replacement Values can be used in specifying the filenames of variables in the awenv.ini file. Several commonly
used Replacement Values are described in the table that follows.

Replacement Value Description

{aw_home} Works for UNIX or Windows.

{/} UNIX= /
Windows = \

{pid} The process_id of the program using the variable.

{program} The name of the program using the variable.

{engine} or {master} The name of the Automation Engine.

Replacement Values as well as parameters defined in the awenv.ini file are not case sensitive. The C programs
interpret the parameters, which uppercase them automatically. Therefore, case is not a factor.
Variables
The variables for processes and clients in general, are set by the awenv.ini environment initialization file. The
variables are described below for information purposes only.
We strongly recommend not altering the awenv.ini file without first consulting with Broadcom Support.

Name Units Default Description

agent Alpha-numeric --- The name of the

Agent. This replaces
SO_OPERATOR.

AgentClientPort number --- The return port for

AgentService process
communications to other
processes. If you do not
specify a value for the
AgentClientPort port, 0
will be used. This lets TCP/
IP pick random ports each
time the processes are
started. This is the typical
situation when a firewall is
not in place.

AgentIP IP address --- Allows you to manually

set the Agent IP address if
gethost does not return it.

UpdateAgentTimeout number --- Used to get a value

greater than the default
of 60 seconds for the
ResponseTimeout
variable. It is only added to
the Automation Engine's
awenv.ini and the
RmiServer process needs
to be bounced for it to take
effect.
 Applications Manager 9.4.1

Name Units Default Description

appworx_port Filename --- Used to determine the

port for awcomm to use
if the port number is not
available from the service's
file.

AWCOMM_PORT number 2136 The Applications

Managerawcomm
communications process
must be directed
to a specific port to
communicate through a
firewall. The default value
for the awcomm port is
2136. It is registered with
the Internet Assigned
Numbers Authority, so
it should not need to be
changed.

check_interval Numeric 60 • The number of seconds

Applications Manager
waits before checking if:
• the listed servers are
alive
• the servers have
exceeded the
MAX_RUN_TIME, and
if so, if the servers have
been stopped

DB_PORT Numeric 1521 The JDBC database port

number. By default, it is the
standard SQL listener port
1521. Each Automation
Engine can have its own
port number.

debug true/false false Turns on debug for

the RmiServer and
AgentService processes.

debug_mask --- --- See Debugging the

awcomm and awnetex C
Processes.

during_wait Numeric 60 The number of seconds

between checks of 'during'
conditions. Minimum value
is 60.

job_start_limit Numeric 10 The maximum number of

tasks started in the current
Queue before tasks are
started on another Queue.
This variable ensures load
balancing occurs equally
on Queues with equal
priorities.
 Applications Manager 9.4.1

Name Units Default Description

LogFileZipSize Number 50 When log files grow to

approximately this number
of megabytes, Applications
Manager automatically
rolls them over. When
Applications Manager
finishes writing to a log, it
auto-zips it to save disc
space.

LogDirectoryPurgeSize Number 500 When the log directory

reaches this number of
megabytes, it is purged.

master Alpha-numeric --- The name of the

Automation Engine.

MasterAgentEncryption Y/N Y Specifies whether you to

use the Secure Sockets
Layer protocol between
the Automation Engine and
Agent(s).

Master_IP_Address Alpha-numeric --- The IP address of the

Automation Engine. This
value is required.

MasterServerPort number ---- The RmiServer listener

port. If you do not
specify a value for the
MasterServerPort port,
the range of values of
60010 through 65535
will be used. This lets
Applications Manager pick
random ports each time
the processes are started.
This is the typical situation
when a firewall is not in
place.
This port is only ever
specified in the Automation
Engine's awenv.ini file.

MasterServerPortStart number 60010 The port to start searching

for an available port when
MasterServerPort=0 or is
unspecified.

radebuglevel Numeric 0 Sets Job submit and

run debug for all Rapid
Automation tasks. The
range of options is 0-9
where 0 is no debug
and 9 is full debug. To
turn this debug off, set
radebuglevel=0.
 Applications Manager 9.4.1

Name Units Default Description

read_timeout Numeric 120 The number of seconds

before a network read
timeout. If exceeded, the
socket is closed.

ResponseTimeout Numeric 60 The number of seconds

before a request between
the RmiServer and
AgentService processes
times out.

RMIServerIP IP address --- An optional setting to

specify the RMI server IP
address for the connection
checker. The IP address
specified here should
be the same as the
IP address specified for
the Master_IP_Address
above.

ServerLogRetentionDays Numeric 7 The number of days before

the oldest log files get
deleted from the server.

sleep_wait Numeric 1 After issuing a database

wait command, the number
of seconds to wait to
ensure the command
has been received and
processed.

so_ext_action --- --- Activates Tivoli logging.

For more information,
see the Tivoli log file
documentation.

sosched_flag --- FALSE If set to TRUE, after

running a Process Flow
requestor Job, Applications
Manager will switch to the
next highest priority Queue
and run a Process Flow
requestor Job if one exists
in that Queue.

start_timeout Numeric (seconds) 600 The number of seconds

a task can remain in the
STARTING status before
Applications Manager
changes the status to
DEAD.
 Applications Manager 9.4.1

Name Units Default Description

UseNetworkTime Y/N Y In effect so the RmiServer
will not make calls to
the master database
every 5 minutes to get
the database time and
the AgentService will no
longer make calls every 5
minutes to get the master
time from the RmiServer.

Options.properties File
The Options.properties file controls many of the client behaviors.
The location for the Options.properties file is:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

Editing the Options.properties File

After making any changes to the Options.properties file, you must stop and restart the RMI process going to the
site directory and issuing the following commands:
For UNIX:

. sosite
stopso rmi
startso rmi

For Windows:

sosite
stopso rmi
startso rmi

Commonly Used Parameters

The most commonly used parameters are described below.

Option Default Description

ClientRMIPortNumber 0 Used with firewalls. Contact

Broadcom Support for more
information.
 Applications Manager 9.4.1

Option Default Description

DatabaseIdleTimeout 30 Causes the RmiServer to close any

database connection which has not
been used for the specified number
of minutes. Setting it to 0 will disable
this function.
It should be set to at least 5 minutes
less the database connection
timeout value. This check is only run
every 5 minutes, so if this option is
set to 55 minutes, the connection will
be closed after 55 to 60 minutes of
inactivity.

Debug false If set to true, turns on debug for the

servers and clients. Takes effect the
next time a server or client is cycled.

DistributorPort 0 Firewall setting. Check with

Broadcom Support.

ExitPage ../Intro.html When using the Java plug-in, sets

the page displayed when a User
exits the Applications Manager
desktop.
The Java plug-in is no longer
supported.

FileViewerFont Not set by default Sets the default font for the File
Viewer window.

HistoryRetentionTime 30 The number of minutes worth of

History stored on the RMI server.
This determines the amount of
history displayed in the Applications
Manager client when you log into a
session.
Warning: The more History
kept for the RMI server, the
more memory you will use,
and the longer it will take to
log into a client session.

HistoryPurgeTimeInterval 30 The number of minutes that history

on the RMI server is removed.

IdleLogoffTime 0 Number of minutes of inactivity

before an auto-logout of the Java
client. To unset this option, set
IdleLogoffTime=0.

jDateFormatMacro MM-dd-yyyy Sets date format for entry fields in

month, day, year.

jDateFormatMicro HH:mm:ss z Sets time format for entry fields in

hours, minutes, seconds, and time
zone.
 Applications Manager 9.4.1

Option Default Description

jTimeOffset HH:mm:ss Sets time format for time offset fields

in hours, minutes, seconds, and time
zone

JobUpdateLimit 1000 Limits the number of tasks a User

can update (e.g.: Delete, Hold) at
one time in Backlog and History

OutMgrMaxRows 200 Number of output files listed in the

Output window.

ProcessFlowRequestor false Because Process Flow requestor

Jobs are obsolete for most
customers, you must set
ProcessFlowRequestor=true to
have them be a selectable Job type
on the Select job type window.

RMIDataPortNumber 0 Used with firewalls. Contact

Technical Support for more
information.

RMIHostID null IP address of the RMI server.

RMIMasterIPAddress null IP address the Automation Engine

uses when talking to Agents. Use
only when you want the IP address
of the Automation Engine thread of
the RMI server to be set individually
for communication with the Agents.

RMIRegistryPortNumber 1099 Port number of the RMI registry.

RMIServerHostname null Used with firewalls. Contact

Technical Support for more
information.

RMISocketTimeout 300 seconds If the RMI server does not respond

within the number of seconds
defined, Applications Manager will
return a connection error.

ServerLog serverLog.txt Name of the server log.

SocketTimeout 60 seconds If the RMI server cannot connect

to the Applications Manager
Automation Engine in the number
of seconds defined, Applications
Manager will return a connection
error.

SSL on Secure socket layer.

UpdateIntv 3 seconds
 Applications Manager 9.4.1

Option Default Description

UserLanguageFiles false Searches for user changed

client language files when
UserLanguageFiles=true. If you
have not edited language in a
previous Applications Manager
version, keeping this setting false
will speed the login time to for
Applications Manager sessions.
KIKI: Translating languages for
the Applications Manager client
is a legacy feature that is now
desupported.

Masters.properties File
When you install Applications Manager, IP address information is written to the Masters.propertes file located in
the data directory. You can edit the Masters.properties file to update the database password.
Text from a sample Masters.properties file is shown below.

CollectorMaster=PROD
PROD=222.4.4.60 v90 1521 AE102 Y ENC\:HqRZc2Gu5JNRwPHgtadjCw\=\= ENC
\:8kD3K2Cj5twSdOPhbKDkSw\=\=
Collectors=222.4.4.60:7099

Masters.properties Options
Each of the possible lines in the Masters.properties file are described below.

Option Description

CollectorMaster This is a legacy option that was used for AppMaster

configuration in previous versions of Applications
Manager.

<Automation Engine name> One required line for this Automation Engine in the
format <Automation Engine name>=<IP address>
<Login name> <port> <service name or PDB service
name for Oracle 12c and above> <Encrypted Y/N>
ENC:<encrypted User name>\=\= ENC:<encrypted
password>\=\=. You may need to edit this file change
the default Oracle login and password, for more
information, see Changing the Default Oracle Login and
Password in Applications Manager .

Collectors This is a legacy option that was used for AppMaster

configuration in previous versions of Applications
Manager.

After Manually Editing the Masters.properties File

After manually editing the Masters.properties file, you must stop and restart the RMI process going to the site
directory and issuing the following commands:
For UNIX:

. sosite
 Applications Manager 9.4.1

stopso rmi
startso rmi

For Windows:

sosite
stopso rmi
startso rmi

Setting Up SSH Shared Keys

SSH and its derivatives (SFTP, SCP, etc.), require an interactive login when connecting to a remote host. This
means that someone must be at the keyboard and able to type in the password required to connect to any given
account on the target remote host. This creates a problem with Applications Manager because the shell running
the command is non-interactive. Therefore, when the ssh command comes back and asks for a password from the
User, Applications Manager is unable to continue and will stop at that point.
Fortunately, SSH supports a method by which password key files can be generated in an encrypted fashion and
handed out between hosts before the actual ssh command is run. Two key files are generated during this process,
one key file must remain on the source host, and the other key file must be transferred to the target host. The
generated key file that remains on the source host is referred to as an identification file. The generated key file that
will be transferred to the target host is referred to as a public key or generated public key.

If these files are created on a source host (A) and properly installed on a remote host (B) for a specific User
account, ssh will not prompt for a password when connecting from A to B. Note that the public key file must match
the id file, so these files will not work without each other. Also, if the public key does not match the id file, or if the
connecting User has not distributed a key file, ssh will default back to an interactive login and will prompt for a
password.
The remainder of this document consists of a series of steps on how to generate and install these key files for most
unix systems. Please note that UNIX configurations vary from system to system, therefore these steps might not
work on all systems and configurations.
Generating the Shared Key Files on the Source Host
On the source host machine (A), while logged in as the User that will be connecting to the remote host, issue the
following command:

ssh-keygen -t rsa
 Applications Manager 9.4.1

The system will then prompt you for a filename for the key file. Just hit enter without specifying a filename.
The system will then prompt you for a passphrase. Just hit enter without specifying a passphrase to leave it blank.
If the system prompts you for the "same passphrase again" to verify what was typed above, just hit enter.
After processing for a second or two, the system should come back with some information about the key file pair
that was just generated. The public key file must now be installed on the target remote host and the remote host
must be told to use this key for the given User.
Transfer the generated public key file to the target remote host. For instance:

scp <users home directory>/.ssh/id_rsa.pub root@<remote hostname>

Loading the Key File on the Target Remote Host

The following instructions assume that ssh shared keys have not already been configured on the remote host
system. If ssh shared keys have already been configured on the system, do not proceed with this document.
Instead, refer to the configuration already in place. Also, note that UNIX configurations vary from system to system,
therefore these steps might not work on all systems and configurations.
While logged in as root on the target remote host (B), you will need to create a directory to store the public keys. Do
this by issuing the following command:

mkdir /etc/sshd/authorized_keys

You will then need to modify the sshd_config file located in /etc/sshd/. Inside that file, you should see a line that
looks like this:

#AuthorizedKeysFile .ssh/authorized_keys

Change it to:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Restart the sshd service with this command:

/etc/init.d/sshd restart

After the restart is complete, move the public key file that was generated on the source host system (A) to the
appropriate location on the target remote system (B). If the file was copied to the remote host using the command
listed in the previous section above, this command will move the file into the correct location:

mv /root/id_rsa.pub /etc/ssh/authorized_keys/<local user accountname>

Where <local user accountname> is the account name that will be used for logging into the target remote host (B)
when connecting via ssh. This should be the account name of the User account created on the target remote host
(B).
 Applications Manager 9.4.1

This completes the installation of SSH shared keys. Test this configuration by logging into the correct User account
on the source host machine (A) and issuing an ssh command as follows:

ssh <remote host username>@<remote host system name>

If this command comes back and informs you that the host key is not cached, just type yes to store the host key
identity. If the shared keys are functioning properly, you should be immediately placed at a command prompt on the
remote host.
If the command prompts you to enter a password during the connection, then the shared keys installation is not
functioning properly and should be re-configured.

Preinstalled Job and Process Flow Descriptions

To get your Applications Manager installation up and running, Applications Manager ships with a number of pre-
installed Jobs and Process Flows that are ready to use. They are used for a variety of functions such as testing,
system maintenance, and file transfers. Each of the Jobs and Process Flows is described below.

Job/Process Flow Description

AGENT_LOG_ROLLOVER Job Controls the Agent service log's rollover interval. Agent
service logs are retained in the log directory for seven
days. They are named AgentService.<data and
time>.log.

BULK_CHANGES Job Allows you to make bulk changes to the characteristic of

Jobs and Process Flows.

CALC_AVE_RUN Job Creates a report of average, last, or maximum task runs

and optionally populates the Ave run time field for Jobs
and Process Flow components.

CALC_HISTORY_STATISTICS Job This Job is included in the AppWorx_History_Stats

import. It compiles data for Applications Manager
History Analysis Reports. For more information, see
Retrieving Historical Data for Applications Manager
Historical Analysis Reports.

CREATE_FISCAL_CALENDAR Job Creates a fiscal calendar.

DELETE_FISCAL_CALENDAR Job Deletes an unwanted fiscal calendar.

FORECAST Job Generates schedule data for forecasts and graphical

forecasts.

HISTORY_PURGE Job Deletes History records that are older than the number
of days you specify in a prompt. The Job is included
in the SYSTEM Process Flow with a default value of
60 days. For more information, see Managing System
Records.

IMPEXP Job This Job is executed when you perform an import

or export. You cannot run the Job directly from the
Requests window, but it may be run from a Process
Flow by setting the view name to IMPORT or EXPORT.

JOB_REPORT Job Runs a report that lists all currently defined Jobs, their
descriptions, the programs they run, their Program
Types, and Applications.
 Applications Manager 9.4.1

Job/Process Flow Description

OLDPRTS Job Changes all completed tasks that have a LOG output
function to STORE.

PROCESS_FLOW_REPORT Job Creates a report listing all currently defined Process

Flows, their descriptions, and the components assigned
to them.

PRODSCH Process Flow Generates a production schedule Report.

PURGE_AUDIT_HISTORY Job Purges the aw_audit_table table used for Applications

Manager auditing. For more information, see Enabling
Applications Manager Auditing.

PURGE_CAL_DATES Job Purges past dates in Calendars.

RMI_LOG_ROLLOVER Job Controls the RMI server log's rollover interval. RMI logs
are retained in the log directory for seven days. They
are named rmiserver.<data and time>.log.

SCHCREATE Job This Job runs a program that generates the production
schedule information into the database table
future_temp. The Job is part of the PRODSCH
Process Flow. After the schedule is created, the
SCHPRINT Job prints the schedule from the
future_temp table.

SCHPRINT Job This Job runs a program that formats and prints the
production schedule stored in the future_temp table
produced by the last SCHCREATE Job. The Job is part
of the PRODSCH Process Flow.

SODELETE Job Deletes output files that have exceeded their retention
days or the maximum number of revisions. This Job
is included in the SYSTEM Process Flow with a view
name of DELDEFAULT.
The SODELETE Job does not run a script like most
Jobs, Applications Manager executes Java every time it
runs. Therefore you should not copy this Job and edit its
script.
For more information, see Managing System Records.

STAGING Job Stages Jobs and Process Flows in the Backlog based
on all of their schedules.

STAGING_BY_SCHEDULE Job Stages Jobs and Process Flows in the Backlog based
on select schedules. For example, you may want to
stage a Job that includes two schedules that run with
different prompt values for different departments.

SYSTEM Process Flow Manages daily maintenance on an Agent. Includes the

HISTORY_PURGE and SODELETE (under the alias
DELDEFAULT) Jobs. If there's one Job you should
be sure to run, it's this one. For more information, see
Managing System Records.

TEST_JOB Job Runs a program called test_module that runs for the
number of seconds specified in a prompt. The Job is
useful for testing scheduling strategies. If a non-numeric
value is supplied for the prompt, the Job will abort.
 Applications Manager 9.4.1

Example Objects Available Via Import

The PROMPT_EXAMPLE Job as well as the SAMPLE Process Flow that used to be installed with new installs are
now included in the Examples.exp import file.
The LOADER Job as well as the AWLOADP Program Type that used to be installed with new installs are now
included in the LOADER.exp import file.

Customizable Columns
From the Options window on the Applications Manager desktop, you can select Tables and customize the
columns in the many Applications Manager windows. For procedure instructions, see the User Guide. In the series
of tables below, the default columns are displayed in bold.
Backlog Columns

Column name Description

SO_QUEUE The Queue each task is running on, or will run on.

SO_JOBID The identification number, which Applications Manager

auto-assigns to each task.

SO_LOG_REVIEWED Uses a Y to identify tasks that include comments.

SO_DOC Uses a Y to identify tasks that include documentation

MODULE The name, or alias if defined, of each task.

SO_START_DATE The date each task started executing or is scheduled to

start executing.

SO_JOB_STARTED The time each task is scheduled to start executing. After

a task begins executing, the time it started.

ELASPSED The elapsed time each task ran.

SO_STATUS_NAME The current status of each task.

SO_OPERATOR The Agent or Agent Group where each task will

execute.

REQUESTOR The person that submitted each task or the User

entered as the requestor of the schedule. If nothing is
displayed, a default requestor was not specified.

CHAIN The Process Flow that contained each component. If

a task is not part of a Process Flow, this field will be
blank.

SO_AW_SEQ Used for Applications Manager troubleshooting.

TABLE_FLAG Displays a Q for Backlog and an H for History. This is

sometimes useful when looking at Process Flows. It is
mostly used for troubleshooting.

SORT_COL1 A long sequence number used to sort tasks in

the Backlog. Used for Applications Manager
troubleshooting.

SO_CHAIN_ORDER Component order in a Process Flow.

 Applications Manager 9.4.1

Column name Description

SO_RESTART Displays a Y or N to show whether the Restart once on

abort option is selected in each Job definition.

SO_MODULE Displays the name of each Job rather than its alias.

SO_CHAIN_SEQ The sequence number Applications Manager

associates with each Process Flow definition.

SO_CHAIN_ID The unique number assigned to each Process Flow at

the time the Process Flow is executed.

JOB_STARTED The date, time and time zone each task started.

SO_JOB_FINISHED The date, time and time zone each task finished

SO_REQUEST_DATE The date, time and time zone each task was requested
or scheduled.

SO_CONDITION Codes for conditions. An @ symbol means

no conditions. Used for Applications Manager
troubleshooting.

SO_STATUS Used for Applications Manager troubleshooting.

SO_USER_SEQ Used for Applications Manager troubleshooting.

SO_JOB_SEQ Each Job's sequence number. Used for Applications

Manager troubleshooting.

SO_EXECUTE_ORDER Numbers Applications Manager assigned to tasks in the

Backlog that determine which are run first.

SO_SCHED_FLAG Displays a Y or N to show whether each task is a

Process Flow. Both Process Flows and schedule Jobs
display a Y.

SO_DETAIL_THREAD This field is no longer used.

SO_AVE_RUNTIME Displays the average run-time for Process Flow

components.

SO_PRINTER_TYPE Sequence number for Output Groups.

SO_REF1 Used by several application solutions. In OAE and

PeopleSoft, it is used to display the application run ID.

SO_PARENTS_JOBID Displays the parent Process Flow's run_id for Process

Flow components.

SO_SEQ_NO Sequence number assigned when task is launched.

SO_APPLICATION Displays the Application assigned in the Job or Process

Flow's definition.

SO_PREDECESSORS Lists each task's predecessors.

SO_REF2 - SO_REF9 Mostly for Applications Manager troubleshooting.

SO_JOB_DESCR Displays the description assigned in each Job or

Process Flow's definition.
 Applications Manager 9.4.1

Column name Description

SO_GROUP_NAMES The Agent Group name for Process Flow headers.

Mostly for Applications Manager troubleshooting.

SO_GROUP_SEQ The Agent Group sequence number for Process

Flow headers. Mostly for Applications Manager
troubleshooting.

SO_PRIORITY Displays the priority assigned to each Job or Process

Flow.

SO_RETURN_CODE Displays the return code of completed tasks.

SO_SINGLE_RUN Displays a Y or N to show whether the Single run

option is selected in each Job definition.

INTERNAL_USE Internal use of the Automation Engine.

SO_CHILD_COUNT Displays the number of Process Flow components for

each Process Flow.

CONDITIONS_CHANGED Mostly for Applications Manager troubleshooting. You

may never see a change in this field from the client.

AW_SCH_NAME Displays the schedule that ran each Job or Process

Flow.

SO_VIRTUAL_DAY The original start time of each task.

SO_PREDECESSOR_JOBIDS Run IDs of satisfied external predecessors.

SO_APPLICATION_STATUS Used by several application solutions including OAE

and PeopleSoft to display the task status in that
application.

History Columns

Column name Description

SO_QUEUE The Queue each task is running on, or will run on.

MODULE The name, or alias if defined, of each task.

SO_JOB_FINISHED The time each task finished executing.

ELAPSED The elapsed time each task ran.

SO_STATUS_NAME The current status of each task.

SO_OPERATOR The Agent or Agent Group where each task executed.

REQUESTOR The person that submitted each task or the User

entered as the requestor of the schedule. If nothing is
displayed, a default requestor was not specified.

CHAIN The Process Flow that contained each component. If

a task is not part of a Process Flow, this field will be
blank.

SO_JOBID The identification number, which Applications Manager

auto-assigns to the task.
 Applications Manager 9.4.1

Column name Description

SO_LOG_REVIEWED Uses a Y to identify tasks that include comments.

SO_CHAIN_SEQ The sequence number Applications Manager

associates with each Process Flow definition.

TABLE_FLAG Displays a Q for Backlog and an H for History. This is

sometimes useful when looking at Process Flows. It is
mostly used for troubleshooting.

SORT_COL1 A long sequence number used to sort tasks in

the Backlog. Used for Applications Manager
troubleshooting.

SO_CHAIN_ORDER Component order in a Process Flow.

SO_RESTART Displays a Y or N to show whether the Restart once on

abort option is selected in each Job definition.

SO_MODULE Displays the name of each Job rather than its alias.

SO_CHAIN_ID The unique number assigned to each Process Flow at

the time the Process Flow is executed.

JOB_STARTED The date, time and time zone each task started.

SO_JOB_STARTED The date each task started executing or is scheduled to

start executing.

SO_START_DATE The date each task started executing or is scheduled to

start executing.

SO_REQUEST_DATE The date, time and time zone each task was requested
or scheduled.

SO_CONDITION Codes for conditions. An @ symbol means

no conditions. Used for Applications Manager
troubleshooting.

SO_STATUS Used for Applications Manager troubleshooting.

SO_USER_SEQ Used for Applications Manager troubleshooting.

SO_DOC Uses a Y to identify tasks that include documentation

SO_JOB_SEQ Each Job's sequence number. Used for Applications

Manager troubleshooting.

SO_EXECUTE_ORDER Numbers Applications Manager assigned to tasks in the

Backlog that determine which are run first.

SO_SCHED_FLAG Displays a Y or N to show whether each task is a

Process Flow. Both Process Flows and schedule Jobs
display a Y.

SO_DETAIL_THREAD This field is no longer used.

SO_AVE_RUNTIME Displays the average run-time for Process Flow

components.

SO_PRINTER_TYPE Sequence number for Output Groups.

 Applications Manager 9.4.1

Column name Description

SO_REF1 Used by several application solutions. In OAE and

PeopleSoft, it is used to display the application run ID.

SO_PARENT_JOBID Displays the parent Process Flow's run_id for Process

Flow components.

SO_SEQ_NO Sequence number assigned when each task is

launched.

SO_APPLICATION Displays the application assigned in each Job or

Process Flow's definition.

SO_PREDECESSORS Lists each task's predecessors.

SO_REF2 - SO_REF9 Mostly for Applications Manager troubleshooting.

SO_JOB_DESCR Displays the description assigned in each Job or

Process Flow's definition.

SO_GROUP_NAMES The Agent Group name for Process Flow headers.

Mostly for Applications Manager troubleshooting.

SO_GROUP_SEQ The Agent Group sequence number for Process

Flow headers. Mostly for Applications Manager
troubleshooting.

SO_PRIORITY Displays the priority assigned to each Job or Process

Flow.

SO_RETURN_CODE Displays the return code of completed tasks.

SO_SINGLE_RUN Displays a Y or N to show whether the Single run

option is selected in the Job definition.

SO_DIRECT_PARENT_JOBID Displays the parent Process Flow's run_id for Process

Flow components.

SO_CHILD_COUNT Displays the number of Process Flow components for

each Process Flow.

CONDITIONS_CHANGED Mostly for Applications Manager troubleshooting. You

may never see a change in this field from the client.

AW_SCH_NAME Displays the schedule that ran each Job or Process

Flow.

SO_VIRTUAL_DAY The original start time of each task.

Output Window Columns

Column name Description

STATUS The output function set for each task

SO_JOBID The identification number, which Applications Manager

auto-assigns to each task.

SO_MODULE The name, or alias if defined, of each task.

SO_USER_NAME The User (requestor) of each task.

 Applications Manager 9.4.1

Column name Description

SO_CREATE_DATE The date and time each output file was created.

SO_OPERATOR The Agent or Agent Group where each task executed.

SO_CHAIN_NAME The Process Flow that contained each component. If

the task is not part of a Process Flow, this field will be
blank.

SO_BYTES The size of each output file in bytes.

SO_PRINTER The Output Device assigned to each task. Output will

only print to this Output Device when the task runs if the
tasks output function is set to PRINT.

SO_PRINTER_SEQ Sequence number for each Output Device.

SO_FILE_ID Sequence number for each file.

SO_USER_SEQ Used for Applications Manager troubleshooting.

SO_PRINT_FLAG Displays a letter for each output function. Use the

STATUS column for this information.

SO_FULL_PATHNAME Displays the full path and file name for each output file.

SO_PRINTER_TYPE Sequence number for Output Groups.

SO_ROLE_OBJECT Used for Applications Manager troubleshooting.

SO_UL_SEQ Used for Applications Manager troubleshooting.

FILENAME Displays the file name for each output file.

PRINT_LOG_CREATE_DATE The date, time and time zone when each log file was
created.

PRINT_LOG_DELETE_DATE The date, time and time zone when each log file will be
eligible for deletion by the SODELETE Job.

Agent Summary Columns

Column name Description

SO_OPERATOR The name of each Agent, Agent Group, or Automation

Engine.

SO_STATUS_NAME The current status of each Agent.

NODE_TYPE Identifies each Agent as an Automation Engine (M),

Agent (A) or Agent Group (G).

LAST_STATUS Gives the date and time when each Agent data was last
updated.

SO_MAX_JOBS The number of threads available for each Agent.

BACKLOG The number of tasks in the Backlog.

RUNNING The number of tasks RUNNING.

 Applications Manager 9.4.1

Column name Description

ONHOLD The number of tasks on HOLD.

ABORTED The number of tasks ABORTED in the Backlog.

SCHEDULED The number of Process Flows in the Backlog.

SO_MASTER Displays a letter for each Automation Engine, Agents, or

Agent Groups. Use the SO_OPERATOR column for this
information.

SO_LAST_ACTIVITY The date, time and time zone of the last activity on each
Automation Engine or Agent.

SO_BP_MESG Used for Applications Manager troubleshooting.

SO_COMMAND Used for Applications Manager troubleshooting.

COLS Used for Applications Manager troubleshooting.

ORD Used for Applications Manager troubleshooting.

SO_IP_ADDRESS The IP Address for each Automation Engine or Agent.

SO_SCHED_DESCR Displays the Thread Schedule associated with each

Automation Engine or Agent.

SO_OP_SYS The operating system for each Automation Engine or

Agent

SO_STATUS Sequence number that relates to each Agent status.

Used for Applications Manager troubleshooting.

SO_OPER_SEQ Sequence number for each Agent.

Queue Summary Columns

Column name Description

QUEUE Name of each Queue.

STATUS Displays whether each Queue is active or inactive.

PRIORITY The priority assigned to each Queue.

SLOTS Number of threads assigned to each Thread Schedule.

BACKLOG The number of tasks in the Backlog waiting to run on

each Queue.

SCHEDULE The Thread Schedule assigned to each Queue.

COLS Used for Applications Manager troubleshooting.

SO_QUEUE_SEQ The Thread Schedule assigned to each Queue. Use the

SCHEDULE column.

ORD_COL Used for Applications Manager troubleshooting.

Process Flow Summary Columns

 Applications Manager 9.4.1

Column name Description

CHAIN The name of each Process Flow.

SO_JOBID The identification number, which Applications Manager

auto-assigns to each task.

ELEPSED The elapsed time each Process Flow ran.

Backlog The number of tasks in the Backlog that are in each

Process Flow.

Hold The number of tasks on HOLD in each Process Flow.

Aborted The number of tasks ABORTED in the Backlog in each

Process Flow.

Running The number of tasks RUNNING in each Process Flow.

SO_CHAIN_ID The unique number assigned to each Process Flow at

the time the Process Flow is executed.

FINISHED The number of tasks FINISHED in each Process Flow

that are in History.

SO_JOB_SEQ Each Job's sequence number. Used for Applications

Manager troubleshooting.

SO_DOC Uses a Y to identify tasks that include documentation

SO_STATUS Used for Applications Manager troubleshooting.

TABLE_FLAG Displays a Q for Backlog and an H for History.

SO_SCHED_FLAG Displays a Y or N to show whether each task is a

Process Flow. Both Process Flows and schedule Jobs
display a Y.

SO_MODULE Displays the name of each Job rather than its alias.

REQUESTOR The person that submitted each task or the User

entered as the requestor of the schedule. If nothing is
displayed, a default requestor was not specified.

Status Summary Columns

Column name Description

Waiting The number of tasks in the Backlog.

Running The number of tasks RUNNING in the Backlog.

On Hold The number of tasks on HOLD in the Backlog.

Aborted The number of tasks ABORTED in the Backlog.

Task Output Columns

Column name Description

SO_MODULE The name, or alias if defined, of each task.

 Applications Manager 9.4.1

Column name Description

FILENAME The name of each output file.

SO_OPERATOR The Agent or Agent Group where each task executed.

SO_FULL_PATHNAME Displays the full path and file name for each output file.

SO_IP_ADDRESS The IP address of each Agent.

SO_PRINTER_TYPE Sequence number for Output Groups.

SO_FILE_ID Sequence number for the file.

SO_JOBID The identification number, which Applications Manager

auto-assigns to each task.

SO_EXECUTION_ORDER Numbers Applications Manager assigned to tasks in the

Backlog that determine which are run first.

TRUNC_JOBID The identification number, which Applications Manager

auto-assigns to each task. Use the SO_JOBID column
for this information.

SO_BYTES The size of each output file in bytes.

SO_OPER_DESCR Description of each Agent.

Agent Logs Columns

Column name Description

SO_MODULE The name of the process associated with each log.

FILENAME The name of each log file.

SO_CREATE_DATE The date and time each Agent log file was created.

SO_OPERATOR The name of each Agent.

SO_FULL_PATHNAME Displays the full path and file name for each output file.

SO_IP_ADDRESS The IP address of each Agent.

SO_PRINTER_TYPE Sequence number for Output Groups.

SO_FILE_ID Sequence number for the file.

SORT_COL A long sequence number used to sort logs. Used for

Applications Manager troubleshooting.

SO_JOBID The identification number, which Applications Manager

auto-assigns to each log.

SO_BYTES The size of each output file in bytes when it was

created. This value will always be 0, so it isn't exactly a
helpful column to display.

SO_OPER_DESCR The description of each Agent.

SO_DELETE_DATE The date each log file will be eligible for deletion by the
SODELETE Job.
 Applications Manager 9.4.1

Gantt Task Summary Columns

Column name Description

SO_JOBID The identification number, which Applications Manager

auto-assigns to each task.

SO_APPLICATION The Application assigned to each Job or Process Flow.

REQUESTOR The person that submitted each task or the User

entered as the requestor of the schedule. If nothing is
displayed, a default requestor was not specified.

SO_JOB_DESCR The description entered in each Job or Process Flow

definition.

ELAPSED The elapsed time each task ran.

SO_DOC Uses a Y to identify tasks that include documentation

SO_AW_SEQ Used for Applications Manager troubleshooting.

TABLE_FLAG Displays a Q for Backlog and an H for History. This is

sometimes useful when looking at Process Flows. It is
mostly used for troubleshooting.

SORT_COL1 A long sequence number used to sort tasks in

the Backlog. Used for Applications Manager
troubleshooting.

SO_LOG_REVIEWED Uses a Y to identify tasks that include comments.

MODULE Displays the name of each Job rather than its alias.

CHAIN The Process Flow that contained each component. If

the task is not part of a Process Flow, this field will be
blank.

SO_CHAIN_ORDER Component order in a Process Flow.

SO_RESTART Displays a Y or N to show whether the Restart once on

abort option is selected in the Job definition.

SO_QUEUE The Queue each task is running on, or will run on.

SO_MODULE Displays the name of each Job rather than its alias.

SO_CHAIN_SEQ The sequence number Applications Manager

associates with each Process Flow definition.

SO_CHAIN_ID The unique number assigned to each Process Flow at

the time the Process Flow is executed.

SO_STATUS_NAME The current status of each task.

JOB_STARTED The date, time and time zone each task started.

SO_JOB_STARTED The time each task is scheduled to start executing. After

a task begins executing, the time it started.

SO_JOB_FINISHED The date, time and time zone each task finished
 Applications Manager 9.4.1

Column name Description

SO_START_DATE The date each task started executing or is scheduled to

start executing.

SO_REQUEST_DATE The date, time and time zone each task was requested
or scheduled.

SO_CONDITION Codes for conditions. An @ symbol means

no conditions. Used for Applications Manager
troubleshooting.

SO_STATUS Used for Applications Manager troubleshooting.

SO_OPERATOR The Agent or Agent Group where each task will

execute.

SO_USER_SEQ Used for Applications Manager troubleshooting.

SO_JOB_SEQ Each Job's sequence number. Used for Applications

Manager troubleshooting.

SO_EXECUTE_ORDER Numbers Applications Manager assigned to tasks in the

Backlog that determine which are run first.

SO_SCHED_FLAG Displays a Y or N to show whether each task is a

Process Flow. Both Process Flows and schedule Jobs
display a Y.

SO_DETAIL_THREAD This field is no longer used.

SO_AVG_RUNTIME Displays the average run-time for Process Flow

components.

SO_PRINTER_TYPE Sequence number for Output Groups.

SO_REF1 Used by several application solutions. In OAE and

PeopleSoft, it is used to display the Application run ID.

SO_REF2 - SO_REF9 Mostly for Applications Manager troubleshooting.

SO_PARENTS_JOBID Displays each parent Process Flow's run_id for Process

Flow components.

SO_SEQ_NO Sequence number assigned when task is launched.

SO_PREDECESSORS Lists each task's predecessors.

SO_GROUP_NAMES The Agent Group name for Process Flow headers.

Mostly for Applications Manager troubleshooting.

SO_GROUP_SEQ The Agent Group sequence number for Process

Flow headers. Mostly for Applications Manager
troubleshooting.

SO_PRIORITY Displays the priority assigned to each Job or Process

Flow.

SO_RETURN_CODE Displays the return code of completed tasks.

SO_SINGLE_RUN Displays a Y or N to show whether the Single run

option is selected in each Job definition.
 Applications Manager 9.4.1

Column name Description

INTERNAL_USE Internal use of the Automation Engine.

SO_CHILD_COUNT Displays the number of Process Flow components for

each Process Flow.

CONDITIONS_CHANGED Mostly for Applications Manager troubleshooting. You

may never see a change in this field from the client.

AW_SCH_NAME Displays the schedule that ran each Job or Process

Flow.

SO_VIRTUAL_DAY The original start time of each task.

SO_PREDECESSOR_JOBIDS Run IDs of satisfied external predecessors.

ESTIMATED_START_TIME The estimated start time of each task.

ESTIMATED_END_TIME The estimated end time of each task.

ABSOLUTE_START_TIME The actual start time of each task.

ABSOLUTE_END_TIME The actual end time of each task,

SO_APPLICATION_STATUS Used by several application solutions including OAE

and PeopleSoft to display the task status in that
application.

Backlog Task Summary Columns

Column name Description

SO_JOBID The identification number, which Applications Manager

auto-assigns to each task.

SO_APPLICATION The Application assigned to each Job or Process Flow.

REQUESTOR The person that submitted each task or the User

entered as the requestor of the schedule. If nothing is
displayed, a default requestor was not specified.

SO_JOB_DESCR The description entered in each Job or Process Flow

definition.

ELAPSED The elapsed time each task ran.

SO_DOC Uses a Y to identify tasks that include documentation

SO_AW_SEQ Used for Applications Manager troubleshooting.

TABLE_FLAG Displays a Q for Backlog and an H for History. This is

sometimes useful when looking at Process Flows. It is
mostly used for troubleshooting.

SORT_COL1 A long sequence number used to sort tasks in

the Backlog. Used for Applications Manager
troubleshooting.

SO_LOG_REVIEWED Uses a Y to identify tasks that include comments.

MODULE Displays the name of each Job rather than its alias.
 Applications Manager 9.4.1

Column name Description

CHAIN The Process Flow that contained each component. If

the task is not part of a Process Flow, this field will be
blank.

SO_CHAIN_ORDER Component order in a Process Flow.

SO_RESTART Displays a Y or N to show whether the Restart once on

abort option is selected in the Job definition.

SO_QUEUE The Queue each task is running on, or will run on.

SO_MODULE Displays the name of each Job rather than its alias.

SO_CHAIN_ID The sequence number Applications Manager

associates with each Process Flow definition.

SO_STATUS_NAME The current status of each task.

JOB_STARTED The date, time and time zone each task started.

SO_JOB_STARTED The time each task is scheduled to start executing. After

a task begins executing, the time it started.

SO_START_DATE The date each task started executing or is scheduled to

start executing.

SO_REQUEST_DATE The date, time and time zone each task was requested
or scheduled.

SO_CONDITION Codes for conditions. An @ symbol means

no conditions. Used for Applications Manager
troubleshooting.

SO_STATUS Used for Applications Manager troubleshooting.

SO_OPERATOR The Agent or Agent Group where each task will

execute.

SO_USER_SEQ Used for Applications Manager troubleshooting.

SO_EXECUTE_ORDER Numbers Applications Manager assigned to tasks in the

Backlog that determine which are run first.

SO_SCHED_FLAG Displays a Y or N to show whether each task is a

Process Flow. Both Process Flows and schedule Jobs
display a Y.

SO_DETAIL_THREAD This field is no longer used.

SO_AVE_RUNTIME Displays the average run-time for Process Flow

components.

SO_PRINTER_TYPE Sequence number for Output Groups.

SO_REF1 Used by several application solutions. In OAE and

PeopleSoft, it is used to display the application run ID.

SO_PARENT_JOBID Displays the parent Process Flow's run_id for Process

Flow components.
 Applications Manager 9.4.1

Column name Description

SO_SEQ_NO Sequence number assigned when each task is

launched.

SO_PREDECESSORS Lists each task's predecessors.

SO_REF2 - SO_REF9 Mostly for Applications Manager troubleshooting.

SO_GROUP_NAMES The Agent Group name for Process Flow headers.

Mostly for Applications Manager troubleshooting.

SO_GROUP_SEQ The Agent Group sequence number for Process

Flow headers. Mostly for Applications Manager
troubleshooting.

SO_PRIORIRY Displays the priority assigned to each Job or Process

Flow.

SO_RETURN_CODE Displays the return code of completed tasks.

SO_SINGLE_RUN Displays a Y or N to show whether the Single run

option is selected in each Job definition.

INTERNAL_USE Internal use of the Automation Engine.

SO_CHILD_COUNT Displays the number of Process Flow components for

each Process Flow.

CONDITIONS_CHANGED Mostly for Applications Manager troubleshooting. You

may never see a change in this field from the client.

AW_SCH_NAME Displays the schedule that ran each Job or Process

Flow.

SO_VIRTUAL_NAME The original start time of each task.

SO_PREDECESSOR_JOBIDS Run IDs of satisfied external predecessors.

9 Oracle Applications Extension Guide

The Oracle Applications Extension Guide is a comprehensive procedures manual for the
Applications Manager Oracle Applications Extension.
The Oracle Applications Extension Guide is a comprehensive procedures manual for the Applications Manager
Oracle Applications Extension.
The Applications Manager Oracle Applications Extension User Guide is written for individuals responsible
for interfacing Applications Manager and Oracle Application's Concurrent Manager. It is part of the complete
Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
 Applications Manager 9.4.1

• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

About This Guide

The Oracle Applications Extension Guide is a comprehensive procedures manual for the Applications Manager
Oracle Applications Extension.
The Applications Manager Oracle Applications Extension User Guide is written for individuals responsible
for interfacing Applications Manager and Oracle Application's Concurrent Manager. It is part of the complete
Applications Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Introduction to the Applications Manager Oracle

Applications Extension
The Applications Manager Oracle Applications Extension is used to initiate Oracle E-Business Suite programs
directly from Applications Manager and manage programs launched from Concurrent Manager. an Applications
Manager utility creates Applications Manager Jobs for existing Oracle E-Business Suite programs.
Oracle's Concurrent Manager is very good at running single Oracle E-Business Suite programs, but is limited when
trying to create complex multi-program Process Flows with dependencies. Applications Manager easily handles
complex Process Flows with dependencies, passes dynamic parameters, and automates output management. The
Applications Manager Oracle Applications Extension (OAE) for Oracle E-Business Suite (OEBS) Agent combines
the best of both Concurrent Manager and Applications Manager into a unified whole with the additional advantage
of a single point of control.
Using the Applications Manager OAE, you can:
• Initiate Oracle E-Business Suite programs directly from Applications Manager using the full range of
Applications Manager Application management features.
• Create Applications Manager Jobs for existing Oracle E-Business Suite programs.
• Manage, through Applications Manager, user-definable sets of Oracle E-Business Suite programs initiated from
Concurrent Manager.
These three capabilities are described below.
Initiating Oracle E-Business Suite Programs from Applications Manager
To create complex multi-program Process Flows with dependencies, you can build your Process Flow objects in
Applications Manager. Applications Manager can manage and launch Jobs in Concurrent Manager.
 Applications Manager 9.4.1

To accomplish this, Applications Manager created a generic Applications Manager Job called CONCSUB.
CONCSUB runs a PL*SQL procedure to request OEBS programs through Concurrent Manager. Jobs based on
CONCSUB can be added to a Process Flow to take advantage of the full range of Applications Manager scheduling
features and conditions. Also, by initiating OEBS programs from Applications Manager, you can take advantage
of Job monitoring, dynamic parameter passing, and automated output distribution. You also can view the program
output and logs online through the Applications Manager viewer.
We refer to the ability of Applications Manager to initiate OEBS programs as the Applications Manager-Initiated
Interface.
Creating Jobs and Process Flows for Oracle E-Business Suite Programs
Applications Manager includes a utilities that automatically create Applications Manager Jobs for your existing
OEBS programs and Process Flows for your report sets. You can then use the Jobs and Process Flows as you
would any other Applications Manager Job or Process Flow. The utilities allows you to choose one or more
Application Short Names, then reads the necessary information about each program from the Oracle E-Business
Suite tables (e.g.: FND_CONCURRENT_PROGRAMS), and builds the Applications Manager Jobs and Process
Flows for each program.

In prior versions of the OAE, you may have seen references to the MKCONC and MKPA Jobs that were used
to create Applications Manager Jobs for Oracle E-Business Suite programs. MKCONC and MKPA have been
replaced with a custom utility available from the Applications Manager main menu.
Intercepting and Managing Oracle E-Business Suite Programs
Applications Manager also can intercept and manage OEBS programs initiated directly from Concurrent
Manager. Within Applications Manager, you can specify sets of OEBS programs that should be managed through
Applications Manager. When the specified OEBS programs are initiated by whatever mechanism you normally use
to get them into Concurrent Manager (e.g.: a Foundation screen, CONCSUB command, or Windows application),
the sets of programs are 'gated' through Applications Manager. You then can use the Applications Manager
workload balancing and conditions features to control the Jobs, including non-OEBS programs, running on the
system.
Managing and Deleting Output for OAE Jobs
Applications Manager registers the OAE output files where they reside on the Oracle E-Business Suite server.
Once we do that Applications Manager manages the output. Each Job's definition specifies the number of days the
output will be retained by Applications Manager. The SODELETE Job runs nightly in the SYSTEM Process Flow
(under the alias DELDEFAULT). It deletes output files that have exceeded their retention settings.

What's New in the Applications Manager Oracle Applications Extension

Oracle Advanced Queuing
Removed DBMS_PIPE from OAE-related code and replaced the functionality with Oracle Advanced Queuing (AQ).
This change requires a dedicated AQ admin account to manage the AQ tables and Queues.
All OAE related database schema objects can now be created in a dedicated OAE Oracle User, instead of using
APPS User. The existing OAE User can continue to use APPS account to deploy OAE objects or migrate the OAE
setup to the dedicated Oracle User through some easy steps.
Upgrading the OAE Extension
For instruction on upgrading the OAE extension after upgrading Applications Manager, see Upgrading the OAE
Extension.
 Applications Manager 9.4.1

Installing and Upgrading the OAE Extension

To install the Oracle Applications Extension (OAE), you must import the Applications Manager Oracle Applications
Extension objects and set up one or both of the Applications Manager-initiated and Oracle E-Business Suite-
initiated Interfaces.
The most visible component of the Oracle Applications Extension (OAE) is the OAE Agent. Through the OAE Agent
you:
• Set up the Applications Manager-initiated and the Oracle E-Business Suite-initiated interfaces
• Automatically create Applications Manager Jobs for existing OEBS programs
• Define sets of OEBS programs to manage through Applications Manager
The OAE Agent is different from a standard Applications Manager Agent. It is an interface to the Oracle E-Business
Suite database rather than a true Agent installed on a server. However, the OAE Agent is displayed in Explorer and
can be controlled like any other Applications Manager Agent.
You do not need to also define a standard Applications Manager Agent on the same machine as the OAE Agent.
Key Installation Steps
The key steps to installing OAE are:
1. Checking that all prerequisites
2. Setting up Oracle Advanced Queuing
3. Setting up an OAE Oracle user account
4. Creating the Login object to connect to the Oracle E-Business Suite database
5. Verifying database connections
6. Defining the OAE Agent
7. Importing the Oracle Applications Extension objects
Each step is described in this chapter.
Prerequisites for Setting Up the OAE Interfaces
The following are prerequisites for setting up the Oracle Applications Extension:
• When updating the Applications Manager triggers and database tables, submitting and processing of
OEBS programs within the Oracle E-Business Suite instance(s) should be suspended. Stop or pause the
corresponding OEBS Concurrent Manager component(s). Restart the component(s) after successfully
completing the install.
• Have the following information for each OAE Login you wish to create:
• Name and password
• Oracle service name
• Network alias (if required)
• Host IP address of the machine where the database resides
• Database port number
In the event an Agent makes a database connection directly (i.e. OAE Agent, Banner Agent, or any direct database
connection), you need to copy the ojdbc6.jar file to the $AW_HOME/web/classes directory of the Agent. You can
get that file from your ORACLE_HOME/jdbc/lib/ directory or the Oracle website.
You cannot have two Automation Engines accessing the same OAE database or more than one OAE Agent per
OAE instance.
Upgrading the OAE Extension
For instruction on upgrading the OAE extension after upgrading Applications Manager, see Upgrading the OAE
Extension.

Setting Up Oracle Advanced Queuing

Starting with Applications Manager 9.2, OAE uses Advanced Queuing (AQ) to replace DBMS_PIPE package for
messaging.
Before you can create an OAE Agent object, you must set up Oracle Advanced Queuing (AQ) with the following
steps:
 Applications Manager 9.4.1

1. Create an AQ admin am_aq_admin account on the same database where Oracle E-Business Suite (OEBS) is
installed.
For Oracle 12c and above, it is likely on a pluggable DB (pdb). Login the SYS account or the SYS account of the
pdb (12c and above) with sql*plus and entering the following, substituting the text in < > with the appropriate text
for your database:

CREATE USER am_aq_admin IDENTIFIED BY <am_admin_password>

DEFAULT TABLESPACE <tablespace_name>;
TEMPORARY TABLESPACE <temp_tablespace_name>;
ALTER user am_aq_admin quota 100M on <tablespace_name>;

The existing tablespaces can be viewed with the following statement:

SQL> SELECT tablespace_name,contents FROM dba_tablespaces;

am_aq_user_setup.sql
OAE_DROP.sql
OAE_user_setup.sql

2. Create a working directory on the host machine where the database for OEBS resides (/home/oae_install/sql
for example).
3. Copy or FTP the following scripts from the sql directory under the Applications Manager home (for example, C:
\am\sql).

am_aq_admin_setup.sql

4. Create AQ roles and objects. Go to the working directory and login in OEBS's Oracle database as SYS (SYS for
the pdb in 12c and above), run the following script:

@am_aq_admin_setup.sql

This will prompt you for the password for the newly created am_aq_admin account. Provide the password when
prompted.
For Oracle 12c and above with pluggable db (pdb), a SQL*NET tnsname has to be created. Check with your
Oracle DBA for the tnsname connecting to the pdb.
Use the tnsname as part of the password, for example, password@pdb1.
This script will create AQ objects am_oae_message_queue and am_oae_queue_table and the roles to grant
to the AQ user. It starts the queue at the end of the script.
To manually start the queue, from the am_aq_admin user, enter:

EXECUTE DBMS_AQADM.START_QUEUE(queue_name => 'am_oae_message_queue');

 Applications Manager 9.4.1

To manually stop the Queue, from the am_aq_admin user, enter:

EXECUTE DBMS_AQADM.STOP_QUEUE(queue_name => 'am_oae_message_queue');

Setting Up an OAE Oracle User Account

With Applications Manager 9.2, you can choose to whether to use the APPS account to deploy the OAE objects or
to create a separated Oracle account to deploy OAE objects (recommended).

If you are: Then:

Newly installing the OAE Agent Follow these steps to create a dedicated Oracle
account:
1. Login SYS account (SYS for the pdb in 12c and
above) and execute the script in the working
directory. The new user creation script will grant
the new user privileges. The process may cause
re-validation of certain objects. Please avoid peak
hours for this step.

SQL> @ OAE_user_setup.sql <username>

<password>

For example:

SQL> @ OAE_user_setup.sql oae oae

The script will create an Oracle account (OAE for

example) in the APPS_TS_TX_DATA tablespace,
which is the same one used by the APPS account.
If you want to use a different tablespace and quota,
you can modify the Customer section in the script
file. The new account will have all the necessary
roles and privileges, including the AQ privileges
for OAE, as well as the synonyms pointing to the
required objects in APPS.
2. Once the script finished, check the
user_apps_create_log.txt file for errors.
The above dedicated account can be dropped
and re-created and only contains the OAE related
objects. It is more flexible and easier to maintain,
compared to using the APPS account.
 Applications Manager 9.4.1

If you are: Then:

Upgrading from an existing OAE/AM system less than Follow these steps to create a dedicated Oracle
v9.2 and you want to use an Oracle account to deploy account:
OAE objects to separate from the APPS account
1. Login SYS account (SYS for the pdb in 12c and
above) and execute the script in the working
directory:

SQL> @ OAE_user_setup.sql <username>

<password>

For example:

SQL> @ OAE_user_setup.sql oae oae

The script will create an Oracle account (OAE for

example) in the APPS_TS_TX_DATA tablespace,
which is the same one used by the APPS account.
If you want to use a different tablespace and quota,
you can modify the Customer section in the script
file. The new account will have all the necessary
roles and privileges, including the AQ privileges
for OAE, as well as the synonyms pointing to the
required objects in APPS.
2. Once the script finished, check the
user_apps_create_log.txt file for errors.
The above dedicated account can be dropped
and re-created and only contains the OAE related
objects. It is more flexible and easier to maintain,
compared to using the APPS account.
3. Drop the OAE objects from the APPS account by
logging into the APPS account and running the
following to clean it up.

SQL> @ OAE_DROP.sql

Upgrading from an existing OAE/AM system less than 1. Navigate to the working directory described in
v9.2 and you want to continue using the APPS account Setting Up an OAE Oracle User Account, login to the
SYS account and run the following script:

SQL> @am_aq_user_setup.sql

2. Enter the user name (APPS) when prompted. This

script will grant proper privileges on AQ objects to
the APPS user.

Creating OAE Login Objects

To link Applications Manager to an Oracle E-Business Suite Concurrent Manager database, you must create an
Applications Manager OAE Login object. Starting with Applications Manager 9.2, you can create a Login object
 Applications Manager 9.4.1

connecting to a separate Oracle account, other than APPS. In that case, The existing Login to APPS account can
be dropped.
You create the object using the Logins window shown below. If you have more than one database, you must
create a Login for each database.

Procedure
To create an OAE Login:
1. Open the Logins Selector window and click New.
Applications Manager displays the Select Login Type window shown above.
2. From the Select Login Type window, select OAE and click OK.
Applications Manager displays the Logins window shown above.
3. In the Name field, enter the Database Login name for the Oracle E-Business Suite instance.
If you are linking Applications Manager to more than one Concurrent Manager database account, and the
database accounts have the same names (e.g. two database accounts with the username apps), use the
Login <username>@<comment> feature to differentiate the two database account names. Applications
Manager ignores the @<comment> portion of the account name when it connects. For information on creating
a Database Login or using <username>@<comment>.
For example, if Oracle databases running on two hosts (sun1 and dg1) both use the same Database Login
name (sqloper), you could add @sun1 and @dg1 to the Database Login names in order to distinguish them
from one another (sqloper@sun1 and sqloper@dg1).
4. Enter the database password.
5. Enter the Oracle service name.
6. If required, enter a network alias.
You must enter a Network alias if the database resides on a different machine than Applications Manager. You
can also use a Network alias to identify a local database. For example, a SQL*Net Network alias for an Oracle
database.
7. Enter the host IP address of the machine where the database resides. This is used to define the Login for JDBC
use.
8. Enter the database port number.
 Applications Manager 9.4.1

9. To accept the information and close the window, click OK.

When you save the Login definition, Applications Manager automatically encrypts the password and checks the
Encrypted box. You cannot change the Encrypted setting.
Once defined, you can test the connection using the Check button.
Next Step
With the Database Login(s) created, the next step is to define the OAE Agent.

Defining the OAE Agent

You must define an OAE Agent in Applications Manager that will be used by Applications Manager to connect to
the Oracle instance.
When you define a Job in Applications Manager to run a program, you assign an Applications Manager Agent to
the Job that tells Applications Manager where to run the program. OAE Jobs are assigned to the OAE Agent. The
OAE Agent includes many of the same fields as a standard Applications Manager Agent. It also includes a field
where you select the OAE Login, a box where you select which Jobs to intercept, and a button to update the OAE
database tables and triggers.

Defining the OAE Agent

To define an Applications Manager OAE Agent:
1. Open the Agents Selector window and click New.
 Applications Manager 9.4.1

Applications Manager displays the Select agent type window shown above.
2. From the Select agent type window, select OAE and click OK.
Applications Manager displays the Agents window shown above.
3. Complete the standard Agent fields on the General tab.
These are the same fields used to define a standard Applications Manager Agent.
Applications Manager Environment Variable objects do not apply to OAE Agents. Therefore the Environmental
Variables field is grayed out.
4. If you are using run time extensions, check the Runtime Extension box.
Checking this box will cause extra overhead while running Jobs. Most features of run time extensions can be
performed with Output Scans, Notifications, and Environment Variables.
5. In the Login field, select an Applications Manager Login object that contains the information to connect to the
Oracle E-Business Suite instance (typically an apps database account).
6. In the Intercept Jobs box, select whether you want to intercept included Jobs, all but excluded Jobs, or no
Jobs. For more information on included and excluded Jobs, see Intercepting OAE Jobs.
The next step will be to update the Applications Manager triggers and database tables. When updating the
Applications Manager triggers and database tables, submitting and processing of OEBS programs within the
Oracle E-Business Suite instance(s) should be suspended. Stop or pause the corresponding OEBS Concurrent
Manager component(s).
7. Click the Update button to update the OAE database tables and triggers.
8. Restart the component(s) after successfully updating.
9. Click OK to save the Agent.
Next Step
After creating the OAE Agent, the next step is to run an Applications Manager import of OAE objects.

Importing the Oracle Applications Extension Objects

To import the OAE objects, open the Import utility and open the OAE_OBJS file. Before you can import
OAE_OBJS, an OAE Login must be defined.
The first step in the installation process is to import the OAE objects. The OAE objects include the CONCSUB Job
used to run OEBS tasks.
Importing the Oracle Applications Extension objects will make the CONCSUB Job available.
 Applications Manager 9.4.1

Procedure
To import the Oracle Applications Extension objects into Applications Manager:
1. Log into Applications Manager and select Import from the Operations window to open the Import window
shown above.
2. From the File menu, choose Open Import File.
Applications Manager displays the Import Files dialog box
3. Choose import file OAE_OBJS from the list and click OK.
A list of mappable objects appears in the Import window.
4. Select the Map File tab.
5. Open the File menu, select Open Map File, and choose ISAIMPORT.
All objects should now be mapped and the dialog box should look similar to the example above. If any objects
are not mapped, you will need to map them manually.
6. To start the import, click Import.
7. Open the Explorer window and check that the IMPORT task is running.
It will return a FINISHED status when complete.
The Automation Engine and Agent must be running for the IMPORT task to run.
Now You're Ready!
 Applications Manager 9.4.1

That completes the basic OAE installation. You now can create Applications Manager Jobs to run OEBS programs,
and define the OEBS programs Applications Manager will control. These topic are covered in Using OAE Auxiliary
Agent Functions.

Upgrading the OAE Extension

Upgrading Oracle Applications Extension (OAE) is relatively easy. Your existing Applications Manager Jobs that
run Oracle E-Business Suite programs will still work under the new Oracle Application Extension. If you need to
create any additional Jobs from OEBS programs, be sure to use the new creation utility provided in OAE Agent.
See Using OAE Auxiliary Agent Functions.
Before You Begin
Make sure you have upgraded the Applications Manager Automation Engine and its Remote Agents to the
same Applications Manager version. For instructions on performing Automation Engine Agent upgrades, see the
Installation Guide.
In the event an Agent makes a database connection directly (i.e. OAE Agent, Banner Agent, or any direct database
connection), you need to copy the ojdbc6.jar file to the $AW_HOME/web/classes directory of the Agent. You can
get that file from your ORACLE_HOME/jdbc/lib/ directory or the Oracle website.
Updating the OAE Login Object
Choose the Login object for the account to deploy the OAE objects.

If you are: Then:

Installing a new OAE Agent or updating an existing Create a new Login, connecting to the new dedicated
OAE Agent from less than Applications Manager v9.2 OAE account. The AgentService process needs to be
and you want to use a create an Oracle account to restarted to use the new connection. To stop and restart
deploy OAE objects to separate from the APPS account the AgentService processes, you must start by setting
(recommended) the new environment. To set the environment:
1. Go to the $AW_HOME/site directory (%AW_HOME
%\site for Windows).
2. Issue the following command:

. sosite

If you get an sosite not found error, try this

command:

. ./sosite

After issuing the command, you should be returned

to the command prompt where you can stop and re-
start the AgentService process with the following
commands:

stopso agentservice
startso agentservice

Updating an existing OAE Agent from less than Continue to use your existing Login for the APPS user.
Applications Manager v9.2 and you want to continue to
use the Login connecting to the APPS account
 Applications Manager 9.4.1

If the you currently have the OAE Agent installed in the APPS account or another account, your need to log into
that account and run the script OAE_DROP.sql to clean-up all the related objects.

SQL> @OAE_DROP.sql

For instructions, see Creating OAE Login Objects.

Re-Importing the OAE Objects
After upgrading, you must perform a short import to bring the latest OAE objects into Applications Manager. For
instructions on importing the OAE objects, see Importing the Oracle Applications Extension Objects.
Updating the OAE Database Tables and Triggers
You must update the OAE tables and triggers when you upgrade. When updating the Applications Manager
database tables and triggers, submitting and processing of OEBS programs within the Oracle E-Business Suite
instance(s) should be suspended. Stop or pause the corresponding OA Concurrent Manager component(s).
To update the tables and triggers, go to the OAE Agent's definition. On the General tab, click the Update button
shown below.
 Applications Manager 9.4.1

It may take a few minutes for the update to complete. To view the log file from the update, click the View Log
button. The log file in named OAECOPY_update.log and is located in the log directory of the OAE Agent.
Restart the component(s) after successfully updating.

Using OAE Auxiliary Agent Functions

To implement the OAE interaction, you mark the Oracle E-Business Suite programs to include and exclude and
create Jobs and Process Flows from existing Oracle E-Business Suite programs.
There are two ways to run Oracle E-Business Suite programs in Applications Manager. You can:
• Create Applications Manager Jobs and Process Flows for Oracle E-Business Suite programs
• Mark Oracle E-Business Suite programs to run in Applications Manager
When implementing the OAE integration, it is possible that you will run programs both ways.
Creating Applications Manager Jobs and Process Flows
When you create Jobs for Oracle E-Business Suite programs, Applications Manager initiates Oracle Applications
Extension Jobs and inserts them into Concurrent Manager when you request or schedule the Job.

Creating Jobs and Process Flows is the most useful because you can bring to bear all the Applications Manager
scheduling and integration features.
Marking Programs for Interception
 Applications Manager 9.4.1

When a program is marked, Applications Manager manages it whenever it is initiated from Concurrent Manager.
Applications Manager intercepts these Jobs, automatically creates matching CONCSUB Jobs in Applications
Manager, runs the Jobs, and (with a standard Agent installed) captures their output.

You might decide to mark programs when:

• Individual Jobs are submitted to Concurrent Manager by end-users.
• An Oracle E-Business Suite program spawns additional programs.
Accessing OAE Auxiliary Agent Functions
You access the OAE Auxiliary Agent Functions window for an OAE Agent from the Agents Selector window by
selecting an OAE Agent and clicking the Aux button as shown below.
 Applications Manager 9.4.1

The Auxiliary Agent Functions window for the OAE Agent includes the following tabs:
• Query: Allows you to query for Oracle E-Business Suite programs using a variety of criteria. Query results
are informational only, and cannot be used to modify the settings on the other tabs. For more information, see
Querying Oracle E-Business Suite Programs.
• Create Jobs: Allows you to generate Jobs for your OAE Jobs. For more information, see Creating OAE Jobs.
• Create Process Flows: Allows you to generate Process Flows for your OAE report sets. For more information,
see Creating OAE Process Flows.
• Intercept Jobs: Allows you to mark OAE Jobs to be included or excluded for interception. For more information,
see Intercepting OAE Jobs.
To open the Auxiliary Agent Functions window for the OAE, Users need to have the OAE Agent and the Agents
User Authority in one of their User Groups. Users will only be able to edit the OAE Agent, if the OAE Agent is in
one of their User Groups with Edit authorization.

Querying Oracle E-Business Suite Programs

Given the large number of Oracles Applications programs, you may find it useful to get a listing of programs based
on a variety of criteria. You can generate a list by defining a query on the Query tab on the Auxiliary Agent
Functions window for an OAE Agent and clicking the Query button.
Applications Manager 9.4.1
 Applications Manager 9.4.1

You access the OAE Auxiliary Agent Functions window for an OAE Agent from the Agents Selector window by
selecting an OAE Agent and clicking the Aux button.
In the image above, query results are returned for programs with the FND application short name.
Query results are informational only, and cannot be used to modify the settings on the other tabs on the Auxiliary
Agent Functions window.
Field Descriptions
The list below describes the fields on the Query Programs tab.
• Application Short Name
Searches for programs in the selected application.
• Program
Searches for OEBS program name(s). Wildcards % and _ are allowed. The field is case sensitive.
• Program Description
Searches for OEBS program description(s). Wildcards % and _ are allowed.
• Applications Manager Job
Checks Job settings and searches for programs:
• That are already Applications Manager Jobs, when you select Yes.
• That are not yet Applications Manager Jobs, when you select No.
• Without regard to whether they are already Applications Manager Jobs, when you select All.
• SRS
Checks for Standard Report Submission programs and searches for programs:
• That are SRS programs, when you select Yes.
• That are not SRS programs, when you select No.
• Without regard to whether they are SRS programs, when you select All.
• Marked
Choose an entry from the list to specify the option for which to query:
• All. Query for All OEBS programs, regardless of Include/Exclude setting.
• Excludes. Query only for OEBS programs that have been marked Excluded.
• Includes. Query only for OEBS programs that have been marked Included.
• Both. Query for OEBS programs that have been marked (either Included or Excluded).
• Neither. Query for OEBS programs that have not been marked.

Creating OAE Jobs

To create an OAE Job, you use the Create Jobs tab on the Auxiliary Agent Functions to build Jobs for each
Oracle Application program. Use the criteria on the Create Jobs tab to select the Jobs. When you finish selecting
criteria, you create the Jobs by clicking either the Apply or OK button. Apply keeps the window open, whereas OK
closes it. Applications Manager will display a confirmation box when the Jobs have been created. After creating the
Jobs, you can include them in Applications Manager Process Flows, schedule them as individual Jobs, or submit
them on an ad hoc basis from the Applications ManagerRequests window.
 Applications Manager 9.4.1

You access the OAE Auxiliary Agent Functions window for an OAE Agent from the Agents Selector window by
selecting an OAE Agent and clicking the Aux button.
Field Descriptions
The list below describes the fields on the Create Jobs tab.
• Application Short Name
Searches for programs in the selected application. From the list of OEBS programs you can select one or
more programs from which to create Applications Manager Jobs. The creation utility combines data from
the Applications Manager views APPWORX_FND_APPLICATIONS, APPWORX_FND_PROGRAMS, and
APPWORX_FND_FLEX_COL_USAGE with the foundation Job information and the Oracle E-Business Suite
link object to build the new Jobs in Applications Manager.
• Program Name
Searches for OEBS program name(s). Wildcards % and _ are allowed. The field is case sensitive.
• Agent/Group
Select the OAE Agent or Agent Group you want assigned to the Jobs you create.
You cannot change the Agent selection for OAE Jobs and Process Flows in schedules.
• Template Job
Using the Job creation utility involves picking a template Job upon which all the new Jobs will be based.
When creating the new Jobs, the template's program parameters are copied to the new Job(s). This forms the
foundation for all new Jobs. Before creating Jobs, you should edit the template Job to assign the desired default
values.
When you installed OAE, the CONCSUB template Job was created.

Creating OAE Process Flows

To initiate Oracle E-Business Suite report sets from Applications Manager, you must create Applications Manager
Process Flows using the create Process Flow utility.
To create an OAE Process Flow from a report set, you use the Create Process Flow tab on the Auxiliary Agent
Functions to build Process Flow for each Oracle Application report set. Use the criteria on the Create Process
Flows tab to select the report sets. When you finish selecting criteria, you create the Process Flows by clicking
either the Apply or OK button. Apply keeps the Auxiliary Agent Functions window open, whereas OK closes it.
Applications Manager will display a confirmation box when the Process Flows have been created. If you create a
Process Flow with the same name as an existing Job, the Process Flow's name will name will include the suffix _-1.
 Applications Manager 9.4.1

You access the OAE Auxiliary Agent Functions window for an OAE Agent from the Agents Selector window by
selecting an OAE Agent and clicking the Aux button.
Field Descriptions
The list below describes the fields on the Create Process Flows tab.
• Application Short Name
Searches for programs in the selected application. From the list of OEBS programs you can select one or
more programs from which to create Applications Manager Jobs. The creation utility combines data from the
FND_CONCURRENT_PROGRAMS, FND_APPLICATION, and FND_FLEX_COLUMN_USAGES tables with
the foundation Job information and the Oracle E-Business Suite link object to build the new Jobs in Applications
Manager
• Request Set Name(s)
Searches for OEBS request set name(s). Wildcards % and _ are allowed. The field is case sensitive.
• Template Job
Using the Process Flow creation utility involves picking a template Job upon which all the new Jobs will be
based. When creating the new Process Flow, the template's parameters are copied to each component in the
Process Flow.
• Application/Queue/Priority/Single Run
The values you pick in these setting will be set for the Process Flow.
• Create Process Flow Prompts
 Applications Manager 9.4.1

Allows you to specify prompt values for Process Flow components at the Process Flow level. When checked,
Applications Manager creates prompts at the Process Flow level for the component prompts.
The Process Flow prompts will be given the description <Job name>: <prompt description>. For example,
FNDCPRT_SQLLOAD: data.
The value of the component prompts will be #<Process Flow prompt number>. For example, if the value of a
Process Flow component prompt is #3, it will resolve to the value of the third Process Flow prompt each time the
Process Flow is run. For more information of passing prompt values from a Process Flow to its components, see
the Development Guide.
• Consolidate Process Flow Prompts
When checked, components which have prompts with the same description and variable name will be combined
into the same prompt at the Process Flow level. Prompts used in multiple components will have the description
Component: <description>. For example, Component: duration.
This field works in conjunction with the Create Process Flow Prompts option. If this box is checked and that
one is not, nothing will happen.

Intercepting OAE Jobs

Use the Intercept Jobs tab for an OAE Agent to mark programs.
If you selected the Only Includes or All but Excludes option in the Intercept Jobs box on the OAE Agent's
General tab, you must build a list of programs to be excluded or included. You do this on the Intercept Jobs tab on
the Auxiliary Agent Functions window as shown below.
 Applications Manager 9.4.1

You access the OAE Auxiliary Agent Functions window for an OAE Agent from the Agents Selector window by
selecting an OAE Agent and clicking the Aux button.
Procedure
To mark OEBS programs as included or excluded on the Intercept Jobs tab:
1. Select the Include or Exclude radio button to specify the mode for either including or excluding the Jobs you
select.
2. Select the Jobs using the arrow icons.
3. Save the changes you make by clicking either the Apply or OK button. Apply keeps the window open, whereas
OK closes it.
Changing the Include/Exclude Mode for Selected Jobs
To change the include/exclude mode a selected Job, click that the MODE column for that Job's row and select
Include or Exclude.
Suggested Excludes
When managing OEBS programs through Applications Manager, we recommend that you start small. For example,
selecting the All but Excluded processing option and no excludes will intercept all OEBS programs, which could
be many more programs than you are prepared to manage through Applications Manager. It would be better to
start smaller by using the Included Only processing option and include a small number of OEBS programs. You can
include additional OEBS programs as your needs and experience grow.
If you get to a point where you want to use the All but Excludes option, you should be aware of the suggested
excludes for certain OEBS programs, most of which exercise control over Concurrent Manager itself. The
suggested excludes include the following FND programs:
• ABORT
• ACTIVATE
• DEACTIVATE
• FDRSTE
• FNDCPBWV
• FNDREPRINT
• RESTART
• SHUTDOWN
• STARTUP
• VERIFY

Working with Oracle Applications Extension

To initiate an Oracle Applications program from Applications Manager, first create a Applications Manager Job for
the particular OEBS program. The OAE Job can then be requested or included in Applications Manager Process
Flows. Running the OAE Job with appropriate prompt values initiates the OEBS program.
By running Oracle E-Business Suite (OEBS) programs directly from Applications Manager, you can take advantage
of the sophisticated scheduling features, Job monitoring, dynamic parameter passing, and output management.
To initiate an Oracle E-Business Suite program from Applications Manager, you use an Applications Manager OAE
Job. You create these Jobs automatically using the OAE Agent Job creation utility.
OAE Jobs use a Program Type of OAE and contain ten default parameters for the minimum information necessary
to make a request to the Oracle E-Business Suite Concurrent Manager engine.
Any additional prompts required for the OEBS program may be added on the Prompts tab for the OAE Job.
OAE Jobs can be individually requested or included in Applications Manager Process Flows. Running an OAE Job
with appropriate prompt values initiates a particular OEBS program. The best and quickest way to create OAE Jobs
for your OEBS programs is to use the Applications Manager creation utility (see Creating OAE Jobs).
An OAE Job initiates an OEBS program in Concurrent Manager using the OAE PL*SQL procedure. The ten default
parameters plus any prompts you define provide the parameters necessary to initiate the task. The image below
illustrates the process.
 Applications Manager 9.4.1

As the OEBS program is processed through Concurrent Manager, it can take on various Concurrent Manager
status codes (Standby, Error, Waiting etc.). These statuses are monitored by Applications Manager and reported as
the status of each OEBS task in the Applications Manager Backlog when you add the Application Status column
to it. For more information, see Monitoring OAE Jobs.
The Generic CONCSUB Job
The single generic CONCSUB Job, imported as part of the Oracle Applications Extension, lets you quickly set up
and run OEBS programs from Applications Manager. Use the Applications Manager creation utility to automatically
create Applications Manager Jobs from OEBS programs. You are free to modify the Applications Manager Job after
it is created by the utility.
Warning: Because the generic CONCSUB Job is the foundation upon which all OEBS programs are run in
Applications Manager, Broadcom strongly recommends that you not make any modifications to it.

Description of the Generic CONCSUB Job

The generic CONCSUB Job uses the information from the Job definition and the prompts to issue the appropriate
PL*SQL procedure command to run the Oracle E-Business Suite program. By default it is the template used to
specify parameters for OAE Jobs and Process Flow components.
 Applications Manager 9.4.1

OAE Program Parameters

Ten parameters are included in the OAE Program box for the CONCSUB Job as shown above. The first five
contain the minimum information necessary to make a request to Oracle E-Business Suite's Concurrent Manager
engine: user name, user's application short name, user's responsibility, program application short name, and the
name of the program to run. The next five allow you to specify OAE printers and output settings. If you need to
pass additional parameters to the OEBS program, you can add them on the Prompts tab as you would for any
other Job. You can key in parameter values or use the select button to pick them.
The OAE program parameters are grayed out unless you select an individual Agent from the Agent Group field.
If you are running on multiple OAE Agents and you want to set these values, select a single OAE Agent, set the
values, then reselect the OAEGROUP Agent Group. If you want to reset the CONCSUB Job to its default settings,
you can re-import OAE objects. For instructions, see Importing the Oracle Applications Extension Objects.
When you create Jobs from the OAE Agent, Applications Manager automatically adds values to the parameters on
the General tab and creates other prompts as necessary.
The OAE program parameters are described below. You have to assign the Job to an Agent for the program
parameters to be changeable.
• User Name*
The OEBS user name under which the OEBS program runs.
• Application*
 Applications Manager 9.4.1

The application short name under which the OEBS program runs.
• Responsibility*
The responsibility under which the OEBS program runs.
• Program App Short Name
The application short name assigned to the program in Oracle E-Business Suite.
• Job to Run
The name of the OEBS program to run. Programs are sometimes referred to by a longer, plain English name
like 'Active Responsibilities and Users' but this prompt requires the shorter program name, for example
'FNDSCARU'.
• Printer
The OAE printer.
• Printer Style
The OAE printer style.
• Copies
The number of copies to print.
• Save output
Y/N to specify whether to save output in Oracle.
• Print Together
Y/N to specify whether to print together.
*The User Name, Application Short Name, and Responsibility prompts together form a security triple for logging
in to Oracle E-Business Suite and granting privileges. The triple you specify in these prompts must be valid within
the OEBS security system, otherwise the program will not be allowed to run.

Managing OEBS programs through Applications Manager

You can use Applications Manager to manage Oracle E-Business Suite programs submitted directly to the
Concurrent Manager engine in Oracle E-Business Suite.
In addition to scheduling Oracle Applications Extension Jobs from Applications Manager, you can also manage
OEBS-initiated Jobs from Applications Manager. The diagram below shows the relationship between Oracle E-
Business Suite and Applications Manager.

How Applications Manager Manages Oracle E-Business Suite Programs

Applications Manager performs the following steps to manage Oracle E-Business Suite programs submitted directly
to the Concurrent Manager engine:
1. When an Oracle E-Business Suite program is submitted directly to the Concurrent Manager
engine, an Applications Manager database trigger adds 10 years to the program's start date in the
FND_CONCURRENT_REQUESTS table. Because the start date is now in the future, Concurrent Manager
waits to start the program. The Applications Manager trigger also inserts a row into the Applications Manager
JOB_QUEUE table. The insert into the JOB_QUEUE table requests one of the following two options:
• The generic Applications Manager OEBS program Job CONCSUB with prompt values for the specific OEBS
program request.
• A Job whose name exactly matches the OEBS program name and whose Program Type is OAE.
For either option, the name of the OEBS program is used as the Applications Manager view name for the Job
when it runs.
2. When Applications Manager runs the Job (depending on threads, priorities and/or conditions), the Applications
Manager trigger resets the program's start date in the FND_CONCURRENT_REQUESTS table to the current
date and time (i.e. it subtracts the 10 years it added earlier). Concurrent Manager initiates running of the
program.
3. Applications Manager monitors the OEBS program status and displays it in the Applications Manager Backlog.
For more information, see Monitoring OAE Jobs.
Allowing Inactive Applications Manager Users as Requestors
 Applications Manager 9.4.1

If the User that runs the Oracle E-Business Suite initiated Job is inactive, the OAE Agent will fail. If you want to
allow inactive Users to be the requestor of Oracle E-Business Suite initiated Jobs, be sure to check the Allow
requests from non active users Automation Engine option located on the Passwords tab in the Automation
Engine's definition.
Controlling Job Execution
You can manage OEBS-initiated Jobs from Applications Manager by using a number of Applications Manager
features. Some possibilities are outlined below:
• Limit the threads for the Applications Manager Queue(s) through which OAE Jobs execute. For example, if you
are running OAE Jobs through a particular Queue, set the number of threads for the Queue to prevent too many
OAE Jobs from running at the same time.
• Limit the threads for the Applications Manager Agent(s) on which the OAE Jobs execute. For example, if you
are running OAE Jobs on a particular Agent, set the number of threads for the Agent to prevent too many OAE
Jobs from running at the same time.
• Limit the CPU limit for the OAE Agent. You can specify CPU limit for the OAE Agents (or any Agent) be entering
a number in the CPU limit field on the General tab of the OAE Agent. The CPU limit defines the percentage of
CPU usage where Applications Manager will spawn no new Jobs. The default it 99%. You can see actual CPU
usage percentages for Agents in the Cpu column on the Agent Summary on the Explorer window.
• If there is a matching OAE Job for the OEBS program, you can set the priority within the Job definition. The
priority will be taken into account when Applications Manager runs the OAE Job (1=highest priority, 99=lowest).
• If there is a matching OAE Job for the OEBS program, you can add conditions to the Job definition. The Job
conditions will be evaluated when Applications Manager runs the OAE Job.

Monitoring OAE Jobs

You can monitor the status of OAE Jobs in the Applications Manager Backlog, restarting or killing them if
necessary. You can also review a History of all the tasks that ran.
 Applications Manager 9.4.1

Task Status
When an OAE task runs in Applications Manager, the Status column in the Backlog shows the Applications
Manager status. Typical statuses included STAGED, QUEUED, RUNNING, FINISHED, and ABORTED.
OAE Statuses
The Concurrent Manager statuses and corresponding Operations Client display names are listed below:
 Applications Manager 9.4.1

Concurrent Manager Status Applications Manager Status

Cancelled C-Cancelle[d]

Disabled C-Disabled

Error C-Error

No Manager C-No Manag[er]

Normal When Concurrent Manager reports the status of

'Normal,' Applications Manager Reports the more
specific phase code. Phase Codes: C-Complete, C-
Inactive, C-Pending or C-Running

On Hold C-On Hold

Paused C-Paused

Resuming C-Resuming

Scheduled C-Schedule[d]

Standby C-Standby

Suspended C-Suspende[d]

Terminated C-Terminat[ed]

Terminating C-Terminat[ing]

Waiting C-Waiting

Warning C-Warning

The Applications Manager statuses can be 10 characters maximum. Square brackets [ ] show any characters
that will be lost. Note also that there is no modification or interpretation of the Concurrent Manager
statuses-Applications Manager Reports the Concurrent Manager statuses directly. For information on the meaning
of each of these statuses, refer to your Oracle E-Business Suite Concurrent Manager documentation.
Adding OAE-Specific Status Columns to the Backlog
There are two OAE columns you can add to the Backlog:
• APPLICATION STATUS: shows real-time status of the OAE Jobs in the OAE application.
• REF1: shows the OAE Job count number for a Job.
To add the Application Status and Ref1 columns to the Backlog:
1. In Applications Manager desktop, open the Options menu and select Tables.
Applications Manager displays the Setup: Backlog window shown below.
 Applications Manager 9.4.1

2. Locate the SO_APPLICATION and SO_REF1 entries in the DB_NAME column in the lower pane and click the
boxes in the VISIBLE column.
3. Optionally rename the Ref1 column name to Job Count.
4. To save the changes, click OK.
Default User
The procedure described above adds the columns for one particular User. If you want to add the OAE status
columns to Explorer for all Users, you can create a User named DEFAULT_USER, and make the changes outlined
above for that User. For more information on creating a DEFAULT USER, see the Administration Guide.

Storing Values for Variables with OUTPUT_FILE

When you define a Job in Applications Manager, you define parameters such as run-time defaults, execution
options, and output options. You can override these parameters at the time the Job is executed by storing values
in a file defined by the OUTPUT_FILE environment variable and using a run-time extension. When Applications
Manager executes a run-time extension, it checks for values in OUTPUT_FILE.
Getting Values into OUTPUT_FILE
 Applications Manager 9.4.1

To store values in OUTPUT_FILE, add the following type of command to the run-time extension script:

echo <variable name>=`<value>´>$OUTPUT_FILE

An example command is shown below:

echo STATUS_NAME=`WARNING´>$OUTPUT_FILE

Run-time Extensions that Apply

Because the Oracle Applications Extension (OAE) process is no longer launched from the BODY script, some
of the run-time extension scripts are not being used for OAE Jobs. All options below are shown for PREFIX
scripts, but can be used for PREFIX, TROUBLE, SUCCESS, or COMPLETION. The options available for run-time
extension scripts used by OAE Jobs run from Applications Manager are:

Option Description

PREFIX.OAE.<Applications Manager Job> The Job name or alias as it is shown in Backlog.

Example: PREFIX.OAE.MY_OAE_JOB

PREFIX.OAE.<User> The User that requested the task.

Example: PREFIX.OAE.SQLOPER

PREFIX.OAE.<Applications Manager Application> Applications Manager Application the task is assigned

to.
Example: PREFIX.OAE.BATCH

PREFIX.OAE.<OEBS program> The Oracle E-Business Suite program name.

Example: PREFIX.OAE.FNDSCURS

PREFIX.OAE.<OEBS application> The Oracle E-Business Suite application.

Example: PREFIX.OAE.SYSADMIN

PREFIX.OAE.<OEBS user> The Oracle E-Business Suite user for the task.
Example:PREFIX.OAE.SYSADMIN

The OAE.Job is usually the same as the task name, so to avoid duplicate calls if the OAE.JOB is called and the
OAE.OEBS_program is the same, it will not call OEBS_program.
Adding Extension Type Environment Variables
There is an environment variable "extension_type" available to the run-time scripts. Its value will be the type of
run-time script i.e. "JOB", "OA_APPLICATION", etc. This environment variable will be available to any run-time
extension.
The value of this variable can be checked to determine if any action should be taken within the script. This would
be useful if you have more than one extension that could get called.
For example, assume you have an OEBS application called FND and an Applications Manager Application called
FND. You create a PREFIX.OAE.OA_FND and a PREFIX.OAE.AW_FND.
If you don't want them both to execute you can check the value of the extension_type variable from within the script
to make decisions.
Possible values for the "extension_type" variable are:
• OAE
• JOB
 Applications Manager 9.4.1

• PROGRAM
• AW_APPLICATION
• AW_USER
• OA_APPLICATION
• OA_USER
Values Available for the OUTPUT_FILE Environment Variable
The dynamic, per-task environment variables that will be available within any runtime script are listed in Values
Available for the OUTPUT_FILE Environment Variable.

Values Available for the OUTPUT_FILE Environment Variable

The dynamic, per-task environment variables that can be stored in OUTPUT_FILE and will be available within any
runtime script are listed below.

Variable Description

application The Applications Manager Application

APPLICATION_STATUS Used along with PHASE_CODE and STATUS_CODE to

determine Job status in Oracle E-Business Suite.

AW_OFILE Name of the Applications Manager System output file

chain_id The Applications Managerchain_id Replacement Value

chain_seq The Process Flow sequence number assigned to a

Process Flow when it is created.

copies The number of copies selected when the OAE task is

printed

extension_type The value will be the type of runtime script

function The output function for the task (Log/Print/Store)

This variable is the same as SO_OUT_FUNCTION, this
version exists for legacy customers who are already
using it.

Job_seq The Job sequence number assigned to a Process Flow

when it is created.

jobid A unique number assigned to a Job by Applications

Manager at the time the Job runs.
This variable is the same as JOBID, this version exists
for legacy customers who are already using it.

JOBID A unique number assigned to a Job by Applications

Manager at the time the Job runs.

module The Applications Manager Job name

OA_DESCRIPTION Description added to the front of the display name of the

program in Concurrent Manager for AM submitted Jobs.
For example: With the following line in a PREFIX.OAE
script (echo OA_DESCRIPTION=AM_DESCRIP_
$JOBID > $OUTPUT_FILE) the display name for
FNDSCURS submitted from AM in Concurrent Manager
would be changed from the default 'Active Users' to
'AM_DESCRIP_1234 (Active Users)'.
 Applications Manager 9.4.1

Variable Description

OAE_APPL Oracle E-Business Suite application

OAE_OFILE Name of the Oracle E-Business Suite System output file

OAE_PARMS OEBS parameters

OAE_PROGRAM OEBS program name

OAE_RESP OEBS responsibility

OAE_RPT_FILE Name of the Oracle E-Business Suite report file

OAE_SH_APPL OEBS Application short name

OAE_USER Oracle E-Business Suite user

OUTPUT_FILE The Applications Manager output file name

output_required Whether output is required as part of the Job definition

PHASE_CODE Used along with APPLICATION_STATUS and

STATUS_CODE to determine Job status in Oracle E-
Business Suite.

printer The OAE printer

printer_text Specific variable, setting, address, or orientation.

Determined by the print options defined for the spooler.

Queue The Applications Manager Queue for the task

request_id A unique number assigned to a Job by Oracle E-

Business Suite at the time the Job runs.
This variable is the same as REQUEST_ID, this version
exists for legacy customers who are already using it.

REQUEST_ID A unique number assigned to a Job by Oracle E-

Business Suite at the time the Job runs.

SO_APPLICATION The Applications Manager Application

SO_BYTES Size of file to be printed

SO_COPIES The number of copies for the Applications Manager

Output Device

SO_OUT_FUNCTION The output function for the task (Log/Print/Store)

SO_PRINTER The Applications Manager Output Device

SO_PRINTER_TEXT Used to pass control codes to the printer

SO_USER_NAME The User

status Status of the task (e.g.: aborted, canceled, running,

etc.)
This variable is the same as STATUS_NAME, this
version exists for legacy customers who are already
using it.
 Applications Manager 9.4.1

Variable Description

STATUS_CODE Used along with APPLICATION_STATUS and

PHASE_CODE to determine Job status in Oracle E-
Business Suite.

STATUS_NAME Status of the task (e.g.: ABORTED, CANCELED,

RUNNING, etc.)

user The User

Implications of Changing Database Account Passwords

Changing the Oracle E-Business Suite and Applications Manager database account passwords can affect the
behavior of the Applications Manager-initiated and Oracle E-Business Suite-initiated Interfaces. The first requires
updating the OAE database Login object in Applications Manager. The second requires updating all OAE triggers.
Warning: Changing the Applications Manager database account password will affect other aspects of
Applications Manager in addition to the Oracle Applications Extension. We are only concerned with the
Oracle Applications Extension in this guide, so descriptions here apply only to the extension. You are
strongly advised to investigate all the ramifications before changing any password.
Changing an OAE Database Account Password
For an OAE Agent to function correctly, it uses one Applications Manager OAE database Login object to hold the
connection information for each Oracle E-Business Suite instance. If the database password for a particular Oracle
E-Business Suite instance changes, you will not be able to run Jobs through the OAE Agent for that instance
unless you update the connection information in the Applications Manager database Login object.
To update an OAE Database Login:
1. In Applications Manager, open the Logins selector window.
2. Select the Login that has changed and click the Edit button.
3. Update the password and click OK.
Changing the Applications Manager Database Account Password
Each OAE Agent uses the same User name to hold the connection information for the Applications Manager
database account. If the user name password for the Applications Manager database account changes, you must:
• Update the password for the User name.
• Update the database tables and trigger for each OAE Agent.
To update the database Login object for the Applications Manager database account:
1. In Applications Manager, open the Users Selector window.
2. Select the user name that has changed and click the Edit button.
3. Update the password and click OK.
To update the database tables and trigger, do the following for each OAE Agent:
1. Open the Agents window.
2. Select the OAE Agent and click Edit.
3. The next step will be to update the Applications Manager trigger and database tables. When updating the
Applications Manager trigger and database tables, submitting and processing of OEBS programs within the
Oracle E-Business Suite instance(s) should be suspended. Stop or pause the corresponding OEBS Concurrent
Manager component(s).
4. Click the Update button to update the OAE database tables and triggers.
5. Restart the component(s) after successfully updating.
6. Click OK to save the Agent.

Applications Manager Environment Variables for OAE

The following table is a list of Applications Manager Environment Variables used for defining/modifying your
Applications Manager/OAE environment. These are reserved words and should not be used as user-defined
environment variables.
 Applications Manager 9.4.1

Environment Variables Description

SO_CONC_MONTHS Number of months to add to request date for OEBS

requests.

USE_CONCSUB If set to Yes, OAE will use the old CONCSUB

commands to initiate Jobs in Oracle E-Business Suite
instead of the PL*SQL commands used now. If you feel
is it necessary to use the old CONCSUB commands,
please contact Broadcom Support before proceeding.

Additions Made to the Oracle E-Business Suite

Database
Two scripts executed during the Applications Manager Oracle Applications Extension installation make additions to
the Oracle E-Business Suite schema:
• oae_triggers.sql creates the triggers
• oae_objects.sql creates the packages and views
The following scripts are used exclusively to create a custom schema for Applications Manager tables:
• OAE_appworx_apps_tables.sql creates the tables in the custom schema and grants access to the apps
schema
• OAE_apps_synonyms.sql creates the synonyms in the apps schema to the Applications Manager tables in
the custom schema.
• OAE_custom_schema_grants.sql grants privileges to the apps schema.
These database objects are described below.

Object Type Object Name Details

Table appworx_oa_requests Identifies requests being managed

by Applications Manager.

appworx_Agent_table Identifies capture mode: intercept or

exception.

appworx_programs Identifies Oracle EBS programs to

be captured.

Trigger xxappworx_Job_catpure_trg before insert on

fnd_concurrent_requests, for each
row

xxappworx_status_notif_trg after insert on aw_oa_requests, for

each row

Package appworx_oae_pk Internal procedures.

10 PeopleSoft Extension Guide

The Applications Manager PeopleSoft Extension Guide describes how to install, configure and
use the Applications Manager PeopleSoft extension.
The Applications Manager PeopleSoft Extension Guide describes how to install, configure and use the Applications
Manager PeopleSoft extension.
The Applications ManagerPeopleSoft Extension Guide is written for individuals responsible for interfacing
Applications Manager with the PeopleSoft Process Scheduler. It is a comprehensive procedures manual that
 Applications Manager 9.4.1

covers all aspects of the Applications Manager PeopleSoft Extension. It is part of the complete Applications
Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

About This Guide

The Applications Manager PeopleSoft Extension Guide describes how to install, configure and use the Applications
Manager PeopleSoft extension.
The Applications Manager PeopleSoft Extension Guide is written for individuals responsible for interfacing
Applications Manager with the PeopleSoft Process Scheduler. It is a comprehensive procedures manual that
covers all aspects of the Applications Manager PeopleSoft Extension. It is part of the complete Applications
Manager documentation set which includes:
• Getting Started Guide
• Installation Guide
• User Guide
• Development Guide
• Administration Guide
• Oracle Applications Extension Guide
• PeopleSoft Extension Guide
Text Conventions
The following text conventions are used throughout this guide:
• User interface field names, menu items, and window names are written in bold.
• File names and text within scripts are written in bold.
• Variable text is written <within brackets>. In the example below <run ID number> represents the actual run ID
number of a requested Job.
If you submit a large Process Flow, the message will read, 'Task submission in progress: Run ID = <run ID
number>' until all components of the Process Flow have been placed into the Backlog.

Introduction to the Applications Manager PeopleSoft

Extension
The Applications Manager PeopleSoft Extension is fully certified to work with PeopleSoft Enterprise. Applications
Manager takes full advantage of the PeopleSoft Enterprise Component Interface to bring robust enterprise
scheduling and application automation capabilities to PeopleSoft Enterprise.
Functionality
Using the Applications Manager PeopleSoft Extension, you can:
• Initiate and run PeopleSoft processes and Jobs.
 Applications Manager 9.4.1

• Track status of processes and Jobs.

• Capture output from PeopleSoft processes and make the output available for online viewing and for distribution
to multiple Output Devices.
Version Compatibility
The Applications Manager PeopleSoft interface was developed using PeopleSoft Enterprise 8.22, 8.43 through
8.48. The interface may not work with earlier versions of PeopleSoft.
The PeopleSoft Extension only supports Oracle databases.
Managing and Deleting Output for PeopleSoft Jobs
Applications Manager registers the PeopleSoft output files where they reside on the PeopleSoft server. Once we do
that Applications Manager manages the output. Each Job's definition specifies the number of days the output will
be retained by Applications Manager. The SODELETE Job runs nightly in the SYSTEM Process Flow (under the
alias DELDEFAULT). It deletes output files that have exceeded their retention settings.

What's New in the Applications Manager PeopleSoft Extension

The Applications Manager PeopleSoft Extension has not changed since v7.1. Changes in previous Applications
Manager and AppWorx versions are listed below.
Standard Agent No Longer Required in Applications Manager 7.1
A standard Applications Manager Remote Agent is no longer a prerequisite when the PeopleSoft Agent is installed
on a remote machine. Deleting of expired outputs and other miscellaneous cleanup is now performed internally by
Java.
New Action to Restart Jobs in PeopleSoft in AppWorx 7.0.2
A Restart at PeopleSoft action available by right-clicking on the Explorer window restarts Jobs in PeopleSoft.
Selecting this menu item will restart the existing PeopleSoft process rather then resubmitting a new one. This
status will be reflected in Explorer.
Mixed-Case User Names Allowed when You Run Jobs as Other Users in AppWorx 7.0.2
When you select Jobs to run as other users, those users can be in the same case as they are in PeopleSoft.
PeopleSoft Bind Variables in AppWorx 7.0
You can now use momentary inline bind variable replacement methods. For more information, see Specifying
PeopleSoft Parameters for a PeopleSoft Agent.
Create Job Utility on the PSE Agent in AppWorx 7.0
You now query for PeopleSoft programs and create Jobs from the Auxiliary Agent Functions window for a
PeopleSoft Agent. You access the PeopleSoft Auxiliary Agent Functions window for a PeopleSoft Agent from the
Agents Selector window by selecting a PeopleSoft Agent and clicking the Aux button. It is no longer possible to
create PSE Jobs from the Jobs Selector window. For more information, see Creating PeopleSoft Jobs.

Installing the Applications Manager PeopleSoft

Extension
All of the files needed to run the Applications Manager PeopleSoft Extension are included in the Applications
Manager installation. However, to use the PeopleSoft Extension, you must have a valid product key. For more
information, contact Broadcom Support.
To configure the Applications Manager PeopleSoft Extension, you must:
• Define a PeopleSoft Login and User in Applications Manager.
• Copy the psjoa.jar file from the PeopleSoft server to where you will install the PeopleSoft Agent.
• Define the Applications Manager PeopleSoft Agent in Applications Manager.
• Import the PeopleSoft objects into Applications Manager.
• Import the PeopleSoft Component Interface.
• Define permissions for the Applications Manager Agent PeopleSoft User.
If you will be running Jobs as users other than the PeopleSoft super user, you must also do the following:
• Copy the AwPSE.jar file from the Applications Manager PeopleSoft Agent to the PeopleSoft server.
 Applications Manager 9.4.1

• Enable the Signon PeopleCode.

• Define permissions for the Applications Manager PeopleSoft Users.
• Create Applications Manager Users for the corresponding PeopleSoft users.
• Restart the Applications Manager PeopleSoft Agent and PeopleSoft server.
Each of these topics are discussed in this chapter.
Permission Changes
Anytime you make permission changes in PeopleSoft, you should stop and restart the Applications Manager
PeopleSoft Agent. You can do this from the Applications Manager Explorer window.

Defining the PeopleSoft Login and User

The mechanism for connecting Applications Manager to PeopleSoft Enterprise is based on an Applications
Manager Login and a User that match the PeopleSoft batch scheduling user. A PeopleSoft Login is shown below.

If a PeopleSoft program run by an Applications Manager Job requires access to PeopleSoft, you must create an
Applications Manager Login. The Applications Manager Login protects your actual password while giving users
access to programs they need to use.
If you will be running Jobs on more than one PeopleSoft server, you should create a separate Login for each
server. If you want to use the same Login for each Agent, for example PSAM, you can create unique names for
the Logins by appending an `@´ character followed by unique identifying characters. The `@´ and characters
after it will be stripped off at the time of execution. For example, you could use the following naming convention:
PSAM@<server>_<system>. In the image above, the extension "orange_fs" has been added to indicate the Login
is for the "orange" PeopleSoft server and "fs" system.
Creating a PeopleSoft Login in Applications Manager
From the Logins window, fill in the Name, Type, and Password fields described below. Usually this Login will be
for a PeopleSoft batch scheduling user. The user needs to have the ability to run processes.
• Name
PeopleSoft Login name for the batch scheduling user.
• Type
PSE
• Password
PeopleSoft password for the batch scheduling user.
Creating an Applications Manager User
Along with the Login, you must also create a matching User. An example is shown below. The user controls access
to the PeopleSoft Jobs defined in Applications Manager.
 Applications Manager 9.4.1

The User Name must match the name assigned to the Applications Manager Login. The user password entered
here is not used, because the PeopleSoft signon will be used instead.
The Database Login with the correct password is required for the super user.
This user will have User Group access to PeopleSoft through Applications Manager.
For more information on defining Users, see the Administration Guide.
Running Jobs as Other PeopleSoft Users
An User is required for each PeopleSoft user you wish to run Jobs as. User passwords entered here are not used,
because the PeopleSoft signon will be used instead.
Running Jobs as other users in not an option for PeopleTools v8.22. On an v8.22 Agent, all Jobs will run as the
batch user assigned to the PeopleSoft Agent.
Next Step
After defining the Applications Manager Login and User for PeopleSoft, the next step is to install the Applications
Manager PeopleSoft Agent.

Installing the PeopleSoft Agent in Applications Manager

Install an Applications Manager Remote Agent on the PeopleSoft server, and define the Agent in Applications
Manager. Define the PeopleSoft Agent using the PeopleSoft User name and Login you created earlier.
Copying the psjoa.jar File
The psjoa.jar file controls and monitors Jobs launched in PeopleSoft by Applications Manager. It must be copied
from the PeopleSoft directory on the PeopleSoft server to the classes directory on the Applications Manager
PeopleSoft Agent.
 Applications Manager 9.4.1

The location of the psjoa.jar file in PeopleSoft is:

UNIX:

$PS_HOME/appserv/classes

Windows:

%PS_HOME%\appserv\classes

The path to the classes directory is shown below:

UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

If you FTP the file, use the binary setting.

Defining the PeopleSoft Agent in Applications Manager
After installing the Applications Manager Remote Agent on the PeopleSoft server, and defining the generic
Applications Manager Agent, the next step is to define the PeopleSoft Agent. Both Agents are required for full
functionality. You define the PeopleSoft Agent using the Agents window shown below.
 Applications Manager 9.4.1

Be sure to select the User and Login you defined earlier. For field descriptions, click the Help button.
Applications Manager Environment Variable objects do not apply to PeopleSoft Agents. Therefore the
Environmental Variables field is grayed out.
Running Multiple PeopleSoft Agents on the Same Server
If you have multiple PeopleSoft Agents on the same server running the same version of PeopleTools, you can
combine them under one AgentService process (use one psjoa.jar file).
If you have multiple versions you will need to have a separate AgentService process for each PeopleSoft Agent
version. That means a separate Applications Manager Remote Agent for each different version.
Something to be aware of when running multiple AgentService is that when AgentService starts it looks at the
IP address of each Agent to determine if it is one if the Agents that it's responsible for. Therefore if you have more
then one AgentService running on one machine you will have to use an alias for one and an IP address for the
other so each AgentService knows which Agent it is responsible for. This is not necessary if they are on different
machines.
Next Step
After defining the general parameters for the PeopleSoft Agent, the next step is to specify the PeopleSoft
parameters for the Agent on the PSE tab.
 Applications Manager 9.4.1

Specifying PeopleSoft Parameters for a PeopleSoft Agent

On the General tab of the Agents window, you defined the general parameters for an Applications Manager
Remote Agent. To make the Agent specific to PeopleSoft, you use the PSE tab shown below to define PeopleSoft
parameters.

PeopleSoft Information
The fields on the PSE tab are described below.
• PeopleSoft Server IP
The IP address of the PeopleSoft server. This may be different from the IP address you defined for the
Applications Manager PeopleSoft Agent if the Agent resides on a different server than PeopleSoft.
• PeopleSoft Server Port
The port number on the PeopleSoft server. This should be the JOLT listener port. The JOLT listener port is
specified in the PeopleSoft psappsrv.cfg file on the PeopleSoft server.
• Language
The language selected for the PeopleSoft server.
• Output Stable Seconds
The number of seconds the size of an output file must be stable before Applications Manager considers it
complete. For example, in the image above, a file would have to be stable for 2 seconds.
• Output Timeout
The time in seconds Applications Manager will search for output before timing out the search. The location of
output files for PeopleSoft Jobs are specified in the System Output Path and Report Output Path fields on the
General tab of the Job's Job definition. For more information, see Defining PeopleSoft Reports.
• Use momentary inline bind variable replacement method
An inline bind variable is a dynamic value that is referenced in the PeopleSoft process override options. For
more information, see Using the Inline Bind Variables or your PeopleSoft documentation.
After defining the PeopleSoft Agent, you can test the connection with the Test Connection button.
 Applications Manager 9.4.1

Next Step
After defining the PeopleSoft parameters, the next step is to import the PSE_TEMPLATE Job.

Importing the PeopleSoft Objects

The Applications Manager PeopleSoft Extension requires several Applications Manager objects to support the
creation of PeopleSoft Jobs. You must import these objects using the PSE_OBJS import file. The file is placed in
the Applications Managerimport directory when Applications Manager is installed or upgraded.
Procedure
To import the Applications Manager PeopleSoft Extension objects:
1. In Applications Manager, open the Import window by opening the Activities menu and selecting Import.
2. From the File menu in the Import window, select Open Import File.
3. From the list of import files, select PSE_OBJS.
Applications Manager displays the Import window shown below.

4. In the Import window, map "Replace_With_PS_Agent" with the Agent you created.
5. Run the import by clicking the Import button.
6. From the View menu, select Refresh Assigned Objects.
Required Edits for PeopleTools 8.22
PeopleTools 8.22 uses different tables than 8.4x, which the PSE_OBJS import is made for. Therefore, if you are
running 8.22, you will need to edit two of Data Types. They are:
• aw_PSE_Output_formats
• aw_PSE_Output_types
• aw_PSE_users
For the aw_PSE_Output_formats data type, change the SQL to:

select XLATSHORTNAME,XLATLONGNAME from xlattable where

FIELDNAME='OUTDESTFORMAT'

Make sure the Login stays as the PSE Agent's Login.

For the aw_PSE_Output_types data type, change the SQL to:

Select XLATSHORTNAME,XLATLONGNAME from xlattable where fieldname = 'OUTDESTTYPE'

This is just a table name change from PSXLATITEM to xlattable.

For the aw_PSE_users data type, change the SQL from:

select oprid from psuserattr

To:

select oprid from psoprdefn

 Applications Manager 9.4.1

If you have mixed 8.4x and 8.22 Agents in the same Applications Manager instance, you should just leave the
SQL blank for these Data Types. You won't get a list of values for those items, but the values can still be manually
entered.
Next Step
After importing the PeopleSoft objects, the next step is to import the Applications Manager Component Interface.
For more information, see Importing the Component Interface for PeopleTools 8.43 - 8.48.

Importing the Component Interface for PeopleTools 8.43 - 8.48

When you create PeopleSoft Jobs in Applications Manager, you select PeopleSoft parameters from drop-down
lists. The entries in these lists are drawn from the PeopleSoft database. To give Applications Manager access to
the PeopleSoft database, you must import the Applications Manager component interface.
Procedure
To import the Applications Manager component interface:
1. From the Applications Manager product download, copy the zip file AWPS_CI.ZIP to a directory accessible by
Open Application Designer in two tier mode and unpack the zip file.
The zip file creates a directory called AppWorx and a subdirectory called APWRX01.
2. Open Application Designer (the client) for your target database and log in with any account that has privileges to
use Application Designer.
3. In Application Designer, open the Tools menu, point to Copy Project, and select From File.
PeopleSoft displays the Copy from File: Select Project window shown below.

4. Select the APWRX01 subdirectory and click Open.

 Applications Manager 9.4.1

5. Browse to the directory where you placed the APWRX01.ini file and choose the file.
PeopleSoft displays the Copy From File window shown below.

6. Ensure that all the Definition Type(s) are selected. If they are not, click the Select All button.
7. With all the Definition Types selected, click Copy.
PeopleSoft copies the Common Objects project into PeopleSoft. Note that the copy operation might take up to a
minute or so to complete.
If this step does not work, then make sure that both the APWRX01.ini and APWRX01.XML files are writable.
When the copy is complete, you should be returned to the Application Designer window.
Next Step
You have imported the Applications Manager component interface. The next step is to define permissions for the
Applications Manager PeopleSoft User.

Importing the Component Interface for PeopleTools 8.22

When you create PeopleSoft Jobs in Applications Manager, you select PeopleSoft parameters from drop-down
lists. The entries in these lists are drawn from the PeopleSoft database. To give Applications Manager access to
the PeopleSoft database, you must import the Applications Manager component interface.
Procedure
To import the Applications Manager component interface:
1. From the Applications Manager product download, copy the zip file APWRX02 to a directory accessible by
Application Designer in two tier mode and unpack the zip file.
The zip file creates a directory called AppWorx and a subdirectory called APWRX02.
2. Open Application Designer (the client) for your target database and log in with any account that has privileges
to use Application Designer.
3. In Application Designer, open the File menu and select Copy Project.
PeopleSoft displays the Copy from File window shown below.
 Applications Manager 9.4.1

4. Select the APWRX02 subdirectory and click Copy.

5. Browse to the directory where you placed the APWRX02.ini file and choose the file.
PeopleSoft displays the Copy window shown below.

6. Ensure that all the Definition Type(s) are selected. If they are not, click the Select All button.
7. With all the Definition Types selected, click Copy.
PeopleSoft copies the Common Objects project into PeopleSoft. Note that the copy operation might take up to
a minute or so to complete.
If this step does not work, then make sure that both the APWRX02.ini and APWRX02.XML files are writable.
When the copy is complete, you should be returned to the Application Designer window.
8. From the Build menu, select Project.
PeopleSoft displays the Build window shown below.
 Applications Manager 9.4.1

9. Make sure that the Create Tables and Create Views boxes are checked, and that the Execute and build
script radio button is selected.
10. Click the Build button.
Check the lower output window to make sure it built successfully.
Next Step
You have imported the Applications Manager component interface. The next step is to define permissions for the
Applications Manager PeopleSoft User.

Defining Permissions for the Applications Manager PeopleSoft User

Earlier in this chapter, you defined the PeopleSoft Login and User in Applications Manager. When you defined
the PeopleSoft Agent in Applications Manager, the PeopleSoft Login was automatically assigned to the Agent.
You must now give that user access to the PROCESSREQUEST, APWRX_SELECT, and APWRX_PRCSDEFN
component interfaces by assigning the C.I.s to a PeopleSoft permission list that belongs to a PeopleSoft role
assigned to the user. If you are going to install the Applications Manager Component Interface, you also need to
give that user access to the APWRX_PRCSRQSTBC component interface. For more information on whether you
would install the Applications Manager Component Interface, see topic Using the Inline Bind Variables.
Assigning Access to the PROCESSREQUEST Component Interface
When assigning the PROCESSREQUEST component interface, give access to the permissions as shown below.
 Applications Manager 9.4.1

To assign the PROCESSREQUEST C.I. to a permission list:

1. From PeopleTools, select Security, then Permissions & Roles.
2. Select Permission Lists.
3. Click Search and select a permission list.
4. Scroll the tabs running across the top of the display until you can see the Component Interfaces tab. Select the
Component Interfaces tab.
5. Click the "+" button at the end of a row and type "PROCESSREQUEST" in the new row.
6. Click Edit.
PeopleTools displays the window shown above.
7. Select the Method Access settings.
8. To save the settings, click OK.
PeopleTools displays the list of component interfaces.
9. Click Save in the lower left corner of the window.
Assigning Access to the APWRX_SELECT and APWRX_PRCSDEFN Component Interfaces
When assigning the APWRX_SELECT and APWRX_PRCSDEFN component interfaces, give full access to all
permissions. An example for APWRX_SELECT is shown in below.

To assign the APWRX_SELECT, APWRX_PRCSDEFN , and APWRX_PRCSRQSTBC C.I. to a permission list:

1. From PeopleTools, select Security, then Permissions & Roles.
2. Select Permission Lists.
3. Click Search and select a permission list.
4. Scroll the tabs running across the top of the display until you can see the Component Interfaces tab. Select
the Component Interfaces tab.
 Applications Manager 9.4.1

5. Click the "+" button at the end of a row and type "APWRX_SELECT" in the new row.
6. Click Edit.
PeopleTools displays the window shown above.
7. Select the Method Access settings.
8. To save the settings, click OK.
PeopleTools displays the list of component interfaces.
9. Click Save in the lower left corner of the window.
10. Repeat steps 5 - 9, but select "APWRX_PRCSDEFN" instead of "APWRX_SELECT" in step 5.
11. If you are going to install the Applications Manager Component Interface, you also need to give that user
access to the APWRX_PRCSRQSTBC component interface. To do so, repeat steps 5 - 9 again, but this time
select "APWRX_PRCSRQSTBC".
For more information on whether you would install the Applications Manager Component Interface, see topic
Using the Inline Bind Variables.
Next Step
You have now completed installing the basic Applications Manager PeopleSoft Extension. This installation allows
you to run PeopleSoft Jobs as the PeopleSoft batch scheduling user. If you want to use Inline bind variables or run
PeopleSoft Jobs as other users, you must perform the additional steps defined in the next topics.

Using the Inline Bind Variables

An inline bind variable is a dynamic value that is referenced in the PeopleSoft process override options. An inline
bind variable is a field reference (in the form recordname.fieldname), preceded by a colon. For example:

:run_cntl_wf.run_cntl_id.

Due to limitations in the PeopleSoft Processrequest API, there are errors when processes containing bind variables
are submitted. When these Jobs are submitted via Applications Manager you will see an error similar to the
following in the Applications Manager Job's system output file.

Error submiting:PeopleSoft:(65,23) : Inline bind variable for :run_cntl_wf.run_cntl_id not found in the
component buffer. (65,23)

There are two solutions for this problem, each with pros and cons.
Method 1 (Preferred)
If you did not install all the component interfaces described in Importing the Component Interface for PeopleTools
8.43 - 8.48, import the Applications Manager Component Interface APWRX_PRCSDEFN. This interface
temporarily modifies the process override options, substituting hard-coded values before the Job is submitted by
Applications Manager then restoring the original after the Job is submitted.
Pros of Method 1:
• There are no duplication of processes.
• It is easier to implement and maintain.
Con of Method 1:
• It might cause slightly less throughput for Jobs which contain bind variables as those processes are submitted
single threaded.
Method 2
Install the Applications Manager Component Interface APWRX_PRCSRQSTBC. This interface allows passing
of known fields to the PeopleSoft process. To implement the user creates copies of the processes which require
inline bind variables, and modifies the variable names in the copies to reference fields recognized and passed as
prompts by Applications Manager.
Method 2 is not an option for PeopleTools v8.22.
 Applications Manager 9.4.1

Pros of Method 2:
• It does not affect existing process definitions.
• It allows for slightly higher volume since the same process can be submitted at the same time.
Cons of Method 2:
• It requires users to create duplicates of all processes requiring inline bind variables and associated scripts.
• Maintenance is more difficult. If the PeopleSoft process definition changes the Applications Manager Job must
be synchronized.
• If a process script changes, you must remember to change the copied script as well.
Implementing Method 1
APWRX_PRCSDEFN: the "Use momentary inline bind variable replacement method"
Import the project file as described in Importing the PeopleSoft Objects.
Create a Job in Applications Manager. For each bind variable, create a prompt with the variable name equal to the
bind variable name. For example:

:run_cntl_wf.run_cntl_id

A prompt for this example is shown below.

Implementing Method 2
APWRX_PRCSRQSTBC:
Import the project file as described in Importing the PeopleSoft Objects.
 Applications Manager 9.4.1

Create copies in PeopleSoft of any processes containing inline bind variables that will be run via Applications
Manager. See notes below for an example of how to copy a process in PeopleSoft.
Replace current inline bind variables with fields recognized by Applications Manager. For example:

:APWRX_WRK.APWRX_FIELD1

Create Job prompts with those variable names. For example:

variable name= APWRX_FIELD1

If it's entered in the form :APWRX_WRK.APWRX_FIELD1Applications Manager will strip off the :APWRX_WRK.
Copying a Process in PeopleSoft
Copying a process in PeopleSoft is a two part process:
• Part 1: Cloning the Process definition.
• Part 2: Cloning the SQR, Crystal Report, or other script you are trying to run.
For example, to run process AR32000- you would do the following:
Part 1: Cloning the Process definition
To clone the Process definition:
1. Copy the process definition AR32000- found online at PeopleTools -> Process Scheduler -> Process ->
Advanced search tab.
 Applications Manager 9.4.1

2. Enter Type = Crystal and search on AR32000-

3. Create new Process definition with exact setup as AR32000- called APWRX001 (or any name, there is an 8
char limit so you need to increment).
4. On the override parameters page shown below, replace:

-ORIENTP :RUN_CNTL_AR.RUN_CNTL_ID :RUN_CNTL_AR.OPRID

 Applications Manager 9.4.1

With the new reference:

-ORIENTP :APWRX_WRK.APWRX_FIELD1 :APWRX_WRK.APWRX_FIELD2

5. Save the update.

Part 2: Cloning the SQR or Crystal report you are trying to run
 Applications Manager 9.4.1

1. In Windows Explorer navigate to the peoplesoft home directory, and the to the CRW or Crystal report folder.
Example C:\psoft\FSCM88\crw\ENG
2. Find report AR32000-.RPT and clone as APWRX001.RPT
3. The process name has to match the RPT name.

Running Jobs as Other Users

The installation steps outlined in the previous topics in this chapter configured Applications Manager to run
PeopleSoft Jobs as the batch scheduling user. If you want to run Jobs as users other than the batch scheduling
user, you must perform the following steps:
• Copy the AwPSE.jar file from the Applications Manager Agent to the PeopleSoft server.
• Create a user for Signon PeopleCode
• Enable Signon PeopleCode.
• Assign permission to the PROCESSREQUEST component interface for each user that will run Jobs from
Applications Manager.
• Define a matching User for each PeopleSoft user that will run Jobs from Applications Manager.
• Restart the Applications Manager PeopleSoft Agent and PeopleSoft server.
Running Jobs as Other Users not Available for v8.22
Running Jobs as other users in not an option for PeopleTools v8.22. On an v8.22 Agent, all Jobs will run as the
batch user assigned to the PeopleSoft Agent.

Copying the AwPSE.jar File

The AwPSE.jar file implements sign-on code when users other than the PeopleSoft batch process user run
PeopleSoft Jobs. It must be copied from the classes directory on the Applications Manager PeopleSoft Agent to
the PeopleSoft directory on the PeopleSoft server.
The path to the classes directory is shown below:
UNIX:

$AW_HOME/web/classes

Windows:

%AW_HOME%\web\classes

The location of the AwPSE.jar file in PeopleSoft is:

UNIX:

$PS_HOME/appserv/classes

Windows:

%PS_HOME%\appserv\classes

If you FTP the file, use the binary setting.

Next Step
After copying the AwPSE.jar file, the next step is to create a user for Signon PeopleCode if one does not already
exist.
 Applications Manager 9.4.1

Creating a User for Signon PeopleCode

If no Signon PeopleCode functions are enabled, and no Signon User ID has been set, you must create a new User
ID. If your company already as a user-defined, skip this topic.
Signon PeopleCode copies user profile data from a directory server to the local database whenever a user signs on
through Pure Internet Architecture, the portal, or a three-tier Windows workstation. Applications Manager accesses
PeopleSoft through the portal. Signon PeopleCode ensures that the local database has a current copy of the user
profile. If no Signon PeopleCode functions are enabled, and no Signon User ID has been set, you must create a
new User ID, then enable Signon PeopleCode. There are three main steps for creating a new User ID are:
• Create a permission list.
• Create a role.
• Create a user.
Creating a Permission List
To create a permission list for Signon PeopleCode:
1. Log in to PeopleSoft as someone with administrative privileges.
2. Navigate to PeopleTools>Security>Permissions & Roles>Permission Lists.
PeopleSoft displays a Permission Lists window.
3. Select the Add a New Value tab.
4. Enter any name in the Permission List field, for example SignonPermissionList.
5. Click Add.
PeopleSoft displays an unnamed tabbed window.
6. On the General tab:
• In the Description field, enter a few words, such as For Signon PeopleCode purposes.
• In the Time-out Utilities section, check Never Time-out.
7. On the PeopleTools tab, make sure that every entity in the PeopleTools Permissions section is unchecked.
8. Click the Save button.
If you don't see any error messages, then you have successfully created a suitable permission list.
Creating a Role
To create a role suitable for Signon PeopleCode:
1. Navigate to PeopleTools>Security>Permissions & Roles>Roles.
PeopleSoft displays the Roles page.
2. Select the Add a New Value tab.
3. Enter a role name, for example: SignonRole.
4. Click Add.
PeopleSoft displays an unnamed screen with seven tabs.
5. On the General tab, enter a description, for example: For Signon People-Code purposes.
6. On the Permissions tab, in the Permission List column, enter the name of the permission list you created.
7. Click the Save button.
Creating a User
To create a suitable user:
1. Navigate to PeopleTools>Security>User Profiles>User Profiles.
PeopleSoft displays a User Profiles window.
2. Select the Add a New Value tab.
3. Enter a name, for example: SIGNON_USER.
4. Click Add.
PeopleSoft displays an unnamed screen with seven tabs.
5. On the General tab, do the following:
• Enter a description, for example: For Signon PeopleCode purposes.
• Set Symbolic ID to the database account listed in the drop-down menu.
• Create a Password.
 Applications Manager 9.4.1

6. On the ID tab, set ID Type to None.

7. Select the Roles tab.
8. In the Role Name column of the Roles tab, enter the name of the role you created above.
9. Click Save.
Next Step
After creating a user for Signon PeopleCode, the next step is to enable Signon PeopleCode.

Enabling Signon PeopleCode

You must enable Signon PeopleCode to allow Applications Manager access to PeopleSoft through the portal.
Many of the columns in the Signon PeopleCode page are case sensitive. Be careful to enter names exactly as the
manual indicates.
Procedure
To enable Signon PeopleCode:
1. Open the PeopleTools menu, point to Security, point to Security Objects, and select Signon PeopleCode
PeopleSoft displays the Signon PeopleCode window. For a detailed discussion of the use of Signon
PeopleCode, see the PeopleSoft documentation.
2. Select Invoke as.
3. Enter the User ID and Password for the account that has permission to run the Signon PeopleCode programs.
PeopleSoft will use this account's context when running Signon PeopleCode programs. If you are installing
Applications Manager on a site that has already configured PeopleSoft, then it is highly likely that a user has
already been designated for this task and you should choose this user. However, if no Signon PeopleCode
functions are enabled and no Signon User ID is already set, then you should create a new User ID for this task.
For more information, see Creating a User for Signon PeopleCode.
4. The Signon PeopleCode page typically already contains several rows. Add a new row by clicking the plus sign
on the final row.
5. In the new row:
• Enter an integer in the Sequence Number column.
Make sure that the existing Signon PeopleCode environment is not dependent on a particular order.
• Place a check mark in the Enabled column.
• Enter APWRX_WRK in the Record column.
• Enter AUTHSSO in the Field Name column.
• Enter FieldDefault in the Event Name column.
• Enter APWRX_CI_LOGIN in the Function Name column.
• Place a check mark in the Exec Auth Fail column. If the User Authentication fails, PeopleSoft will still run the
Job using the User ID specified in the Invoke as User Id field above the table.
6. Click Save.
The resulting page (at least the last line of it) should look as follows:

Next Step
 Applications Manager 9.4.1

After enabling Signon PeopleCode, the next step is to assign the PROCESSREQUEST component interface to a
permission list.

Assigning the PROCESSREQUEST C.I. to a Permission List

For users to run Jobs via Applications Manager, the PeopleSoft users must have access to the Applications
Manager PROCESSREQUEST component interface. Therefore, you must assign the component interface to a
permission list that belongs to a role assigned to the users.
When assigning the PROCESSREQUEST component interface, give full access to the CREATE and SCHEDULE
permissions as shown below.

Procedure
To assign the PROCESSREQUEST C.I. to a permission list:
1. From PeopleTools, select Security, then Permissions & Roles.
2. Select Permission Lists.
3. Click Search and select a permission list.
4. Scroll the tabs running across the top of the display until you can see the Component Interfaces tab. Select the
Component Interfaces tab.
5. Click the "+" button at the end of a row and type "PROCESSREQUEST" in the new row
6. Click Edit.
PeopleTools displays the window shown above.
7. Select the Method Access settings.
8. To save the settings, click OK.
PeopleTools displays the list of component interfaces.
9. Click Save in the lower right corner of the window.
Next Step
After assigning the PROCESSREQUEST component interface to a permission list, the next step is to create the
Users.

Creating Applications Manager Users

For each user that will be running PeopleSoft Jobs from Applications Manager, you must create a User. In
Applications Manager, access to the Applications Manager client is controlled by a user name and password. User
Groups assigned to the user in Applications Manager control the user's ability to create and run Jobs.
When you create the User, the name must be identical to the PeopleSoft user name.
Note that in order to assign other users as the requestor of a Job or Process Flow, you must have the Select
Requestors User Option assigned to your user by your Applications Manager administrator.
Next Step
 Applications Manager 9.4.1

After creating the Users, the next step will be to restart the Applications Manager PeopleSoft Agent and PeopleSoft
server. See the next topic for the correct sequence.

Restarting the PeopleSoft Agent and PeopleSoft Server

You have made a number of changes on the PeopleSoft server. For the changes to take effect, you must restart the
Applications Manager PeopleSoft Agent and the PeopleSoft Server.
Procedure
To restart the Applications Manager PeopleSoft Agent and the PeopleSoft Server:
1. Stop the Applications Manager PeopleSoft Agent from the Applications ManagerExplorer window.
2. Stop the PeopleSoft server.
3. Restart the PeopleSoft server.
4. Restart the Applications Manager PeopleSoft Agent.

Upgrading the PeopleSoft Extension

Upgrading PeopleSoft Extension (PSE) is relatively easy. Your existing Applications Manager Jobs that run
PeopleSoft programs will still work under the new PeopleSoft Extension. If you need to create any additional Jobs
from PSE programs, be sure to use the new creation utility provided in the PSE Agent.
Before You Begin
Make sure you have upgraded the Applications Manager Automation Engine and its Remote Agents to the
same Applications Manager version. For instructions on performing Automation Engine Agent upgrades, see the
Installation Guide.
Re-Importing the PSE Objects
After upgrading, you must perform a short import to bring the latest PSE objects into Applications Manager. For
instructions on importing the PSE objects, see Importing the PeopleSoft Objects.

Defining PeopleSoft Jobs

In PeopleSoft, a single program is called a process. A series of processes that run in the background are called a
Job. To run a PeopleSoft process, you create a Applications Manager Job. To create the equivalent of a PeopleSoft
Job, you add two or more Jobs to a Applications Manager Process Flow. The image below illustrates the difference
in naming conventions.
 Applications Manager 9.4.1

The following topic describes how to create Applications Manager Jobs to run a PeopleSoft processes. For
information on creating Process Flows, see the Development Guide.
Applications Manager Jobs
A Job is the basic building block in Applications Manager. For each program you want to run (PeopleSoft , FTP,
database load, etc.), you create a Job. A Job specifies all the information required to run a program including:
• The program name: the task that will be run.
• Parameters: run time defaults, execution options, output options.
• Prompts: information that is passed to the program as variables.
Assumptions
This chapter assumes that you are already knowledgeable about creating Applications Manager Jobs and
PeopleSoft Jobs. For example, we assume you know how to complete the general information required for all
Applications Manager Jobs. For detailed information, we reference the appropriate chapter in the Development
Guide.
We assume that you know how to define a PeopleSoft Job and its parameters. We provide brief descriptions of the
PeopleSoft fields, but then reference you to the PeopleSoft documentation.
Accessing PeopleSoft Auxiliary Agent Functions
You access the PeopleSoft Auxiliary Agent Functions window for a PeopleSoft Agent from the Agents Selector
window by selecting a PeopleSoft Agent and clicking the Aux button as shown below.
 Applications Manager 9.4.1

The Auxiliary Agent Functions window for the PeopleSoft Agent includes the following tabs:
• Query: Allows you to query for PeopleSoft programs using a variety of criteria. Query results are informational
only, and cannot be used to modify the settings on the Create Jobs tab. For more information, see Querying
PeopleSoft Programs.
• Create Jobs: Allows you to generate Jobs for your PeopleSoft Jobs. For more information, see Creating
PeopleSoft Jobs.
To open the Auxiliary Agent Functions window for the PeopleSoft, Users need to have the PeopleSoft Agent and
the Agents User Authority in one of their User Groups. Users will only be able to edit the PeopleSoft Agent, if the
PeopleSoft Agent is in one of their User Groups with Edit authorization.

Querying PeopleSoft Programs

You can query for PeopleSoft programs using a variety of criteria. Query results are informational only, and cannot
be used to modify the settings on the Create Jobs tab.
Given the large number of PeopleSoft programs, you may find it useful to get a listing of programs based on a
variety of criteria. You can generate a list by defining a query on the Query tab for the PSE Agent and clicking the
Query button.
 Applications Manager 9.4.1

In the image above, query results are returned for programs with the SQR Process Program Type.
You access the PeopleSoft Auxiliary Agent Functions window for a PeopleSoft Agent from the Agents Selector
window by selecting a PeopleSoft Agent and clicking the Aux button.
Query results are informational only, and cannot be used to modify the settings on the Create Jobs tab.
Field Descriptions
The list below describes the fields on the Query tab.
• Program
Searches for a PSE program name.
• Program Type
Searches for a PSE Program Types.
• Server
Searches for PSE programs limited by a server.
• Applications Manager Job
Checks Job settings and searches for programs:
• That are already Applications Manager Jobs, when you select Yes.
• That are not yet Applications Manager Jobs, when you select No.
• Without regard to whether they are already Applications Manager Jobs, when you select All.

Creating PeopleSoft Jobs

To create an PeopleSoft Job, you use the Create Jobs tab for the PSE Agent to build Jobs for each PeopleSoft
program. Use the criteria on the Create Jobs tab to select the Jobs. When you finish selecting criteria, you create
the Jobs by clicking either the Apply or OK button. Apply keeps the PSE Agent definition open, whereas OK
closes it. Applications Manager will display a confirmation box when the Jobs have been created. After creating the
Jobs, you can include them in Applications Manager Process Flows, schedule them as individual Jobs, or submit
them on an ad hoc basis from the Applications ManagerRequests window.
 Applications Manager 9.4.1

You access the PeopleSoft Auxiliary Agent Functions window for a PeopleSoft Agent from the Agents Selector
window by selecting a PeopleSoft Agent and clicking the Aux button.
Field Descriptions
The list below describes the fields on the Create Jobs tab.
• Program Name
Searches for PeopleSoft programs. Wildcards % and _ are allowed. The field is case sensitive.
• Agent/Group
Select the PSE Agent or Agent Group you want assigned to the Jobs you create.
• Template Job
Using the Job creation utility involves picking a template Job upon which all the new Jobs will be based.
When creating the new Jobs, the template's program parameters are copied to the new Job(s). This forms the
foundation for all new Jobs. Before creating Jobs, you should edit the template Job to assign the desired default
values.
When you ran the PSE_TEMPLATE import, the PSE_TEMPLATE Job was brought into Applications Manager.
Use it as your template Job. For information on importing PSE_TEMPLATE, see Importing the PeopleSoft
Objects.
For information on editing PeopleSoft Jobs, see Editing PeopleSoft Jobs.

Editing PeopleSoft Jobs

You create PeopleSoft Jobs using the Create Jobs tab of the PSE Agent described in Creating PeopleSoft Jobs.
Once defined, you can edit Jobs from the Jobs window the way you would any other Applications Manager Job.
The Jobs window for a PeopleSoft Job is similar to a standard Applications Manager Job, except the fields in the
Program group box have been modified for PeopleSoft.
 Applications Manager 9.4.1

The fields in the PeopleSoft Program group box are described below.
• Process or Job
Select the name of a Job or a process.
If you select the name of a Job, the format is:

<job name>-|-PSJob

If you select the name of a process, the format is:

<process name>-|-<process type>

• Requestor
This is the PeopleSoft user name that will be used to run the Job or process. The PeopleSoft User must have
access to the PeopleSoft Process Request Component Interface to support Applications Manager submitting
Jobs through the PeopleSoft API.
 Applications Manager 9.4.1

There must be a matching User name defined as well. The User is needed to control access to objects within
Applications Manager. If no requestor is specified, the Agent's User will be used.
• Run Control ID
In PeopleSoft, a run control ID stores a set of parameters used to run a process or Job. Select or enter the
required ID. The run control ID replaces prompts in a regular Applications Manager Job.
• PeopleSoft server name
Enter or select the server on which you want the Job to execute. If blank, PeopleSoft will determine the server.
• Output Format
The PeopleSoft output format to be used with this Job. Enter a format, or click the Select button to choose a
format from a list.
• Output Type
Enter or select a PeopleSoft output type.
• Destination
This is the PeopleSoft destination.
If the output type you selected is FILE, enter a fully defined path.
If the output type you selected is EMAIL or WEB, you can enter:
• a specific destination such as sales@abc_company.com.
• U:<user name> to specify the email address of a PeopleSoft User.
• R:<role name> to specify the email address of a PeopleSoft role.
You can enter multiple destinations by separating them with semicolons.
• System Output Path*
Enter the fully-pathed location of the system output file generated by the PeopleSoft process. This field allows
for regular expressions.
• Report Output Path*
Enter the fully-pathed location of the report output file generated by the PeopleSoft process. This field allows for
regular expressions.
*Applications Manager searches all subdirectories in the path, which can be resource intensive. You should make
the paths as specific as possible. Also, you can use Applications Manager PSE variables in the System and Report
Output paths. For information on using variables, see Using Applications Manager PSE Variables in Output Paths.
The Select buttons next to the fields display values drawn from the PeopleSoft application. The checkboxes next to
the fields determine if the values can be changed when the Job is run from the Requests window.

Using Applications Manager PSE Variables in Output Paths

To make it easier to designate the PeopleSoft output files that Applications Manager will capture, you can use a set
of variables. The variables can be used in the System Output Path and Report Output Path fields when defining
PeopleSoft Jobs.
You can use the standard Applications Manager variables, as well as the following variables unique to PeopleSoft:
• PROCESSNAME
• PROCESSINSTANCE
• PROCESSTYPE
• RUNCONTROLID
• JOBNAME
The search will find the output regardless of whether it is written in upper-case or lower-case letters. For example,
the value of {PROCESSNAME} could be XRFWIN or xrfwin.
Example 1 - Searching for Files Named <processname>_<processinstance> in a Directory
Assume the system output is going to a directory called /users/PeopleSoft/log_output, and the naming
convention for the file is <processname>_<processinstance>.
 Applications Manager 9.4.1

You can use the regular expression:

/users/PeopleSoft/log_output/.*{PROCESSNAME}_{PROCESSINSTANCE}.*

The expression will register all the files that contain the regular expression <processname>_<processinstance>
anywhere in their name.
Example 2 - Searching for Files Named <process_name>_<process_instance>.PDF in a Directory
Assume the report output is going to a directory called /users/PeopleSoft/reports. The naming convention for the
file is <process_name>_<process_instance>.PDF.
You can use the regular expression:

/users/PeopleSoft/reports/.*{PROCESSNAME}_{PROCESSINSTANCE}\.PDF

Note the back-slash before PDF. That is a regular expression matching function. Since '.' is a special character, the
'\' escapes the '.' to mean the actual '.' and not the special character for a regular expression.
Since back-slash is an escape character for regular expressions, if the output resides on a Windows machine the
paths must still be entered with forward slashes. For example, assume the output is on c:\PeopleSoft\reports. The
regular expression should be entered as:

c:/PeopleSoft/reports/.*{PROCESSNAME}_{PROCESSINSTANCE}\.PDF

Example 3 - Searching Subdirectories

Applications Manager will search sub-directories for output too. For example, assume that the output distribution
goes to a special folder with a timestamp so when a Job is run, we get a report with a file name that looks
something like /users/PeopleSoft/20050603/XRFWIN_123.PDF.
You can specify the following expression:

/users/PeopleSoft/.*{PROCESSNAME}_{PROCESSINSTANCE}\.PDF

Applications Manager will search for the XRFWIN_123.PDF file starting at the /users/PeopleSoft directory and
search recursively down each sub-directory looking for the file. This is a resource intensive and time consuming
search, so the more specific you can be about the directory, the more efficient the processing will be.

Creating Subvars and Data Types

In Applications Manager, Substitution Variables can return a value from the PeopleSoft database, and Data Types
can retrieve a set of values from a PeopleSoft database table.
Defining Substitution Variables
To define a Substitution Variables that retrieves a value from the PeopleSoft database, enter a SQL statement as
shown below. This activates the Login field. From the Login field, select the PeopleSoft Database Login.
 Applications Manager 9.4.1

Defining Data Types

To define a data type that retrieves a set of values from the PeopleSoft database, enter a SQL statement as shown
below. This activates the Login field. From the Login field, select the PeopleSoft Database Login.
 Applications Manager 9.4.1

Defining PeopleSoft Reports

You can define an Applications Manager Report object that pulls data from the PeopleSoft database. A sample
report is shown below.
 Applications Manager 9.4.1

To create a PeopleSoft report, select the PeopleSoft Database Login from the Login field as shown above. The
Applications Manager component interface restricts SQL statements to one table and five columns. If you need to
access more than one table in a SQL statement, you must use unions.
Note that when creating PeopleSoft reports, if the table name starts with PS_, omit the PS_.
 Applications Manager 9.4.1

Running and Monitoring PeopleSoft Tasks and

Processes
After creating an Applications Manager PeopleSoft Job to run a PeopleSoft process or Job, you can run the Job on
an ad hoc basis from the Requests window, schedule the Job to run automatically at prescribed times, or add the
Job to an Applications Manager Process Flow. In this chapter, we will use the term "Job" to refer to both PeopleSoft
Jobs and processes.
PeopleSoft Jobs vs. Applications Manager Process Flows
If you want to run a series of PeopleSoft Jobs in a set sequence, you can add the PeopleSoft Jobs to an
Applications Manager Process Flow. A Job in PeopleSoft is equivalent to a Process Flow in Applications
Manager, and steps in a PeopleSoft Job are equivalent to components in an Applications Manager Process Flow.
Components in an Applications Manager Process Flow can be Jobs or other Process Flows. The comparison is
shown below.
 Applications Manager 9.4.1

Enterprise Integration
Applications Manager PeopleSoft Jobs and Process Flows work seamlessly with the Applications Manager
environment. Each individual Applications Manager Job calls a PeopleSoft process or Job. By using Applications
Manager schedules, you gain advanced scheduling capability. In addition to using Applications Manager as a
single-point of control for your entire PeopleSoft environment, Applications Manager can also use Process Flows to
run a multitude of Program Types including SQL*Plus, Cobol, Shell, Perl, or C.
Monitoring Jobs
Applications Manager monitors all PeopleSoft Jobs submitted from Applications Manager. The Jobs are displayed
in the Applications Manager Backlog. Two new PeopleSoft columns display PeopleSoft status and run ID number.
Taking Actions on Jobs
From the Backlog, you can take a number of actions on Jobs including putting them on hold, killing them, and
resetting them.

Requesting PeopleSoft Jobs

If you want to run a PeopleSoft Job on an ad hoc basis, you can request the Job from the Requests window shown
below.
 Applications Manager 9.4.1

On the Submit window shown below, you may have the opportunity to specify various options depending on how
the PeopleSoft Job was defined. However, the first two prompts, "Process or Job" and "Requestor" are read only. If
the Hide RO (Read-only) Prompts option is assigned to your user ID, you will not see these prompts.
 Applications Manager 9.4.1

When you submit a Job request, the Job/Process Flow is passed through an Applications Manager Queue. The
Applications Manager Automation Engine examines the Job and routes it to the appropriate Agent for execution.

Scheduling PeopleSoft Jobs and Process Flows

With Applications Manager, you can create schedules to run Jobs and Process Flows on days of the week,
specific days of the month, and days in a Calendar. For example, a PeopleSoft Job that is scheduled to run on the
weekdays at noon is shown below.
 Applications Manager 9.4.1

Monitoring PeopleSoft Jobs

You can monitor the status of PeopleSoft Jobs in the Applications Manager Backlog, restarting or killing them if
necessary. You can also review a History of all the Jobs that ran.
 Applications Manager 9.4.1

Job Status
When a PeopleSoft Job runs in Applications Manager, the Status column in the Backlog shows the Applications
Manager status. Typical statuses include STAGED, QUEUED, RUNNING, FINISHED, and ABORTED.
PeopleSoft Statuses
The PeopleSoft statuses displayed in the Application Status column are described briefly below They are taken
from the PeopleSoft documentation. For a more detailed description, see the PeopleSoft documentation.

Status Definition

Blocked The process is waiting for specific conditions to be met.

Cancelled Indicates that the server Agent has successfully

canceled the request after it has started.
 Applications Manager 9.4.1

Status Definition

Error An error was encountered while processing transactions

within the program.

Initiated The request has been acknowledged.

No Success Indicates that the program encountered an error within

the transaction. No Success is different from Error
because the process is marked as restartable.

Pending Indicates that this item is waiting for a previous item

in the Job to complete before it will be released by
PeopleSoft Process Scheduler.

Processing Indicates the program is running.

Queued Status assigned to a new process request. The process

request remains Queued until a PeopleSoft Process
Scheduler Server picks up the new request.

Restart Indicates that a process encountered an error and is

attempting to restart.

Success Indicates that the program has successfully completed.

Warning A condition assigned to the program has been met,

triggering the display of the Warning status.

Adding PeopleSoft-Specific Columns to the Backlog

There are two PeopleSoft columns you can add to the Backlog:
• APPLICATION STATUS: shows real-time status of the PeopleSoft Jobs in the PeopleSoft application.
• REF1: shows the PeopleSoft Job count number for a Job.
To add the Application Status and Ref1 columns to the Backlog:
1. From the Applications Manager Desktop, open the Options menu and select Tables.
Applications Manager displays the Setup: Backlog window shown below.
 Applications Manager 9.4.1

2. Locate the SO_APPLICATION_STATUS and SO_REF1 entries in the DB_NAME column in the lower pane and
click the boxes in the VISIBLE column.
Applications Manager adds the columns to the display in the upper part of the window.
3. If you wish to change the names of the columns, click in the Name field and enter a new name. For example, in
the image above, the SO_REF1 column name was changed to PS Inst #.
4. To save the changes, click OK.
Default User
The procedure described above adds the columns for one particular User. If you want to add the PeopleSoft status
columns to Explorer for all Users, you can create a User called DEFAULT_USER, and make the changes outlined
above for that User. For more information on creating a DEFAULT USER, see the Administration Guide.

Reviewing PeopleSoft Job Details

If a PeopleSoft Job is in the Applications Manager Backlog or History, you can view details about the Job by
selecting it, right-clicking, and choosing Job Details. The General tab in the Task Details window shown below
shows Applications Manager information about the Job.
 Applications Manager 9.4.1

The Prompts tab shown below displays PeopleSoft-specific information about the task.
 Applications Manager 9.4.1

Taking Actions on PeopleSoft Jobs

When a PeopleSoft Job is in the Applications Manager Backlog, you can take several actions on the Job depending
on its current status. To take an action on a Job, you select the Job in the Backlog, right click, and select the action
from the pop-up menu as shown below.
 Applications Manager 9.4.1

Some of the most common actions you can take are described below.
• If the Job is not yet in RUNNING status, you can take the standard Applications Manager actions on the Job
including HOLD and DELETE.
• If the Job is in RUNNING status, you can KILL the Job, which is equivalent to canceling the Job in PeopleSoft.
• If an action generates an ALERT status on a PeopleSoft Job, you can select Clear Alert.
PeopleSoft Actions
There are several commands displayed at the bottom of the pop-up menu that are specific to PeopleSoft Jobs.
 Applications Manager 9.4.1

Command Description

Clear Alert If an action taken in Applications Manager causes

a PeopleSoft error, the Applications Manager status
bar turns red and an error message is entered in
the Job log. The status in the Application Status
column will change based on the cause of the error.
For example, the status may turn to KILL FAILED or
RELEASE FAILED. Issuing the Clear Alert command in
Applications Manager clears the status and resets the
status bar color.

Detach Separates the Applications Manager Job from the

PeopleSoft Job. The Applications Manager Job goes to
History immediately with a status of DETACHED. The
Job will continue to be processed in PeopleSoft.

Delete at PeopleSoft Deletes the selected Job in PeopleSoft. Can only be

applied to Jobs that do not have an ACTIVE status
in PeopleSoft. This command can be available even
after the PeopleSoft Job has passed to the Applications
Manager History.

Hold PeopleSoft Job Puts a PeopleSoft Job on hold. This status will be
reflected in Explorer.

Restart Job at PeopleSoft Restarts Job in PeopleSoft. Selecting this menu item
will restart the existing PeopleSoft process rather then
resubmitting a new one. This status will be reflected in
Explorer.

Troubleshooting the Applications Manager PeopleSoft

Extension
Because of the many steps required to install the Applications Manager PeopleSoft extension, it is easy to make a
mistake. The most common errors and their solutions are described in this chapter.

Agent Goes to Error

Symptom 1
The Applications Manager PeopleSoft Agent displays an ERROR status. The following message is contained in the
AgentService.log file for the PeopleSoft Agent:

java.lang.NoClassDefFoundError: psft/pt8/joa/JOAException

Cause 1
The most common cause of this error is that the psjoa.jar file can not be found.
Solution 1
Copy the psjoa.jar file from the PeopleSoft server to the $AW_HOME/web/classes (%AW_HOME%\web\classes)
directory.
Symptom 2
 Applications Manager 9.4.1

The Applications Manager PeopleSoft Agent displays an ERROR status. The following message is contained in the
AgentService.log file for the PeopleSoft Agent:

5504 : (0,0) : PeopleTools release (8.46) for web server '' is not
the same as Application Server PeopleTools release (8.44). Access
denied. : null

Cause 2
The wrong version of the psjoa.jar file was installed.
Solution 2
Use the version that matches the PeopleSoft server tools version.
When done, stop and restart the AgentService process. Before starting or stopping processes, you must set the
correct environment by doing the following:
1. Go to the $AW_HOME/site directory (%AW_HOME%\site for Windows).
2. Issue the following command:

. sosite

If you get an sosite not found error, try this command:

. ./sosite

After issuing the command, you should be returned to the command prompt where you can enter the stopso
agentservice and startso agentservice commands to stop and restart the AgentService process.

PSProperties not loaded from file

Symptoms
The following error message is displayed in the AgentService.log file for the PeopleSoft Agent:

PSProperties not loaded from file. Couldn't find file:

pstools.properties

Cause
The PeopleSoft API displays this message. It is not an error.
Solution
You can ignore the message. If you want to prevent the message from being generated, you can copy the
pstools.properties file from the PeopleSoft server to the Applications Managerclasses directory under the web
subdirectory.

5007 : Component Interface APWRX_SELECT must be installed

Symptom
 Applications Manager 9.4.1

When you are defining an Applications Manager PeopleSoft Job, you get an error message when you open one of
the drop-down lists in the Program group box The following text is displayed in the details of the error message:

Caused by: 5007 : Component Interface APWRX_SELECT must be installed.

: null

Cause
The Applications Manager Component Interface has not been installed or permissions to the Component Interface
have not been granted to the PeopleSoft super user.
Solution
Follow the instructions to install the Applications Manager Component Interface. See Importing the Component
Interface for PeopleTools 8.43 - 8.48.

Job Aborts
Symptoms
After completing the installation, a Job aborts when running as a user other then the primary PeopleSoft user (the
User that the Agent runs under). The log file contains an error similar to the following:

(0,0) : (X)[email protected] is an Invalid User ID, or you

typed the wrong password. User ID and Password are required and
case sensitive. Make sure you're typing in the correct upper and
lower case.
Job aborted!
Cause: The connection for the user (GEORGE) failed

Cause 1
The AwPSE.jar file is not loaded for the PeopleSoft server.
Solution 1
Check to make sure:
• The AwPSE.jar file has been installed in the Applications Manager PeopleSoft Agent's classes directory.
• The PeopleSoft server was stopped and re-started at the end of the installation procedure.
• The Applications Manager PSE Agent has been stopped and re-started at the end of the installation procedure.
Cause 2
Signon PeopleCode has not been enabled, or is not properly configured.
Solution 2
Follow the instructions to enable Signon security and re-start the PeopleSoft server and the Applications Manager
PSE Agent.
Test the Applications Manager signon jar file by:
1. Navigating to the PeopleSoft server directory where the AwPSE.jar file exists.
2. Issue the following command:

java -classpath AwPSE.jar com.am.agent.PSE.auth.Base64 testname

 Applications Manager 9.4.1

The results should be:

Encoding:testname
awdecoded:testname

(0,0) : DOWNbea.jolt.ServiceException: Invalid Session

Symptom
An error similar to the following is displayed:

(0,0) : DOWNbea.jolt.ServiceException: Invalid Session

Cause
The PeopleSoft server may not be accessible.
Solution
Check to make sure the PeopleSoft server is accessible. Ping the server IP. Make sure you can connect to the
PeopleSoft application via a browser using the same IP and port.

(90,6) : Not Authorized (90,6)

Symptom
An error like the following is displayed in the Agentmanager log or in a Job's log file when trying to run a Job.

(90,6) : Not Authorized (90,6)

Cause 1
Permissions are missing for the PROCESSREQUEST Component Interface.
To verify this, try submitting the process via the PeopleSoft interface. This will validate that the user has
permissions to submit the process.
Solution 1
Grant permissions to the CI for the user that is running the Job. Be sure to stop and restart the PeopleSoft server
and Applications Manager Agent. For more information, check the PeopleBooks documentation or with your
PeopleSoft administrator.
Cause 2
The Applications Manager PeopleSoft Agent has not been restarted since a permission change was made in
PeopleSoft
Solution 2
Stop and restart Applications Manager PSE Agent.

8. (65,8) : You are not authorized to run...

Symptom
A Job aborts and the following text is including in the log file:

8. (65,8) : You are not authorized to run process type SQR Report and
 Applications Manager 9.4.1

process name XRFWIN. (65,8)

Cause
The user you are attempting to submit the Job under does not have permissions to run the process.
To verify this, try submitting the process via the PeopleSoft interface. This will validate that the user has
permissions to submit the process.
Solution
Grant permissions for the requesting user to run this process.
(Check PeopleSoft doc or with PeopleSoft admin).

Caused by: 5504 : (2,116) : Invalid parameter 1 for function CreateRowset

Symptom
You get an error like the following from the client when you try to define a Subvar or Report:

Caused by: 5504 : (2,116) : Invalid parameter 1 for function

CreateRowset. (2,116) At APWRX_SELECT.Methods apwrxselect PCPC:223
Statement:4 : null

Cause
SQL statement is incorrect.
Solution
Test the SQL in the database to make sure it's correct.
Note that when using the PeopleSoft API, if the table name starts with PS_, omit the PS_.

AwE-9999 Internal Error - index out of range...

Symptoms
When you attempt to create a new PSE Job, Applications Manager displays the following error message:

E5509 PSE Data Types missing, Please import.

Cause
The Applications Manager PeopleSoft objects have not been imported.
Solution
Import the Applications Manager PeopleSoft objects as described in Importing the PeopleSoft Objects.

<User name> is an Invalid User typed the wrong password

Symptoms
An error like the following is displayed in a pop-up window when the PeopleSoft Agent tries to start/connect:

(0,0) : (X)[email protected] is an Invalid User typed the wrong password. User ID and Password
are case sensitive. Make sure you're typing in the correct lower case.
Job aborted!
Cause: The connection for the user (GEORGE) failed
 Applications Manager 9.4.1

Cause 1 - User Name/Password Incorrect

The user name or password is incorrect.
Solution 1
Check the following and correct as necessary:
• Triple check that the user name and password defined in the DB Login are correct.
• Try logging in to the PeopleSoft application using that user and password.
• Check to make sure the case is correct for the user name and password.
Cause 2 - The Wrong Port for the Connection to PeopleSoft is Specified
Typically you would expect a BEA Jolt exception if it can't access the server, but you may get this misleading error
instead.
Solution 2
Check the following and correct as necessary:
• Check that the URL to the PeopleSoft server and the port specified are correct.
• Determining the correct Jolt URL and port should be done by the PeopleSoft administrator.
To determine the Jolt port of the application server, check the JOLTListener section in the psappsrv.cfg file.
The file is located at <PS_HOME>\appserv\<DOMAIN_NAME>.

A Job Errors in PeopleSoft, but Completes Successfully in Applications Manager

Question
A Job errors in PeopleSoft, but completes successfully in Applications Manager, did it really fail?
Answer
The process didn't fail. This happens when Jobs return a Success status in PeopleSoft indicating that the process
ended successfully. Afterwards, the output distribution occurs and if it fails, PeopleSoft sets the Job status to Error.
PeopleSoft does not make a distinction between the process status and the distribution status. With Applications
Manager, we scan the process message log for the text "process completed successfully". If that text string is
found we set its status to Success.

Troubleshooting Difficult PeopleSoft Job and Process Launch Errors

To test the component interface Applications Manager uses to submit Jobs, you can use the PeopleSoft Application
Designer. By testing directly from the Application Designer you can verify whether the problem is in PeopleSoft
rather than in Applications Manager.
To troubleshoot Jobs or processes from the Application Designer, do the following:
1. From the Application Designer select Open.
The Open Object window shown below opens.
 Applications Manager 9.4.1

2. From the Open Object window, choose Project from the Object Type drop-down list.
3. Find AWPRX01 for 8.4x as shown in the first image below or APWRX02 for 8.22 as shown in the second image.

4. Once the project is loaded, expand the component interface on the left side. For 8.4x, it will be called
APWRX_PRCSRQSTBC, for 8.22 it will be called AWPROCESSREQUEST.
5. To run a test, double-click on the component interface.
The component interface opens in the right side of the window.
6. Right-click on the schedule method on the right side of the screen and select test component interface.
The Component Interface Tester - Enter key values, choose function window shown below opens
minimized.
 Applications Manager 9.4.1

7. From the Component Interface Tester - Enter key values, choose function window, fill in the 'Create' keys
for Component Interface values and hit the Create New button.
The Component Interface Tester window opens.
8. Right-click on APWRX_PRCSRQSTBC for 8.4x as shown below or AWPROCESSREQUEST or 8.22 as shown
below and select Schedule.
Applications Manager 9.4.1
 Applications Manager 9.4.1

If the test is successful, a pop-up window with the process instance will be returned. If the test is unsuccessful,
an error message like the one shown below will be returned.

11 Disaster Recovery
Objective
The objective of this article is to:
• Recover or rebuild the production quickly following a disaster that leads to the destruction of all or a few servers.
• Offer minimum administrator effort during the restoration process.
Scenarios handled
The following scenarios are addressed in this article.
• The server hosting RMI Server is lost.
• The database server is lost.
• The server hosting the Agent Service is lost.
RMI server is lost
If the RMI Server is lost, it needs to be recreated using the following steps.
1. Install Applications Manager.
2. Copy additional scripts/executables from backup.
3. Update the master_ip_address on all servers hosting remote agents using the DRSSHClient script.
An SSH (Secure Socket Shell) server runs on all the servers hosting remote agents. A command is sent to all
remote servers and it gets executed on each server. As a result, master_ip_address gets updated in the awenv.ini
configuration file. Now when you restart the Agent services, agent services on these hosts will connect to the new
RMI Server.
Database server is lost
Note: You must take a regular backup of your database. If the database server is lost, a new database server
needs to be created.
To restore the lost database server.
1. Update the following parameters in the awenv.ini configuration file.
• DB_IP
• NET_CONNECT
The configuration file on the RMI Server needs to be updated to point to the new database server.
Note: If the port or user information is modified, Applications Manager must be reinstalled on the RMI Server.
Remote agent server is lost
Note:
• If the server hosting the remote agent is lost, a new server needs to be recreated.
• You must have a backup of scripts/executables that are executed as part of Jobs.
To recreate a server.
1. Install Applications Manager remote agent.
2. Login to the Client application and update the hostname/IP Address of the agent.
 Applications Manager 9.4.1

The SSH server starts automatically along with the agent service.
Instructions for administrators
• No special installation or setup tasks are required.
• A new section shared has been introduced in the configuration file awenv.ini. The parameters in this section are
updated to the configuration files of the remote agents whenever they are restarted.
• A new process is spawned on each of the remote servers hosting the Remote Agent service. This process
is an SSH server. The SSH Server listens on a port in the range controlled by the configuration parameter
sshdserver_portrange. By default, it is set to 50000:50010. This value is initially set under the shared section
of the configuration file on the RMI Server. However, whenever the Agent service is restarted, the parameter
value gets updated in the configuration file on each of the remote agents.
• Two new configuration parameters cmd_w_updatemaster (for Windows) and cmd_u_updatemaster (for
UNIX) have been added to the awenv.ini file. These parameters point to the script that updates the configuration
file and restarts the agent service on remote servers.
• The SSH Server starts or stops along with Agent Service. You can use the startso all to start the agent
service, and use the stopso all command to stop the agent service. However, if you want only the SSH
server to stop, use thestopso sshdserver command, and use the startso sshdserver command to start
the SSH server.
• To execute disaster recovery remote commands, use the following command on the new RMI Server.

> $AW_HOME/exec/DRSSHClient <hostname/ipaddress of new RmiServer> [optional space

seperated list of remote hosts]

12 Usage Data (Telemetry)

You can configure Applications Manager to collect and send telemetry data — product usage and system
configuration data — to Broadcom. Use the information on this page to learn how to send usage data to Broadcom.
If you are licensed to use this product under a Portfolio License Agreement (PLA) subscription, you must configure
it to collect and send product-specific usage data. If you are licensed to use this product under a standard license,
you can consent to having this product collect and send usage data. By default, this product does not collect and
send usage data.
For Applications Manager, the following options are available.
1. Populate telemetry data.
2. Generate telemetry report.
3. Send the report file to Broadcom.
Populate telemetry data
Note: The AM_TELEMETRY_POPULATE job populates the required data automatically and is scheduled to run
daily by default. If you want to run the job manually, follow the steps mentioned below.
1. In the Applications Manager, go to Activities > Requests.
2. Select AW_TELEMETRY_POPULATE.
3. Click Request.
4. Click Submit & close.
The job starts running, and you can find it under Backlog.
Generate telemetry report
To generate the telemetry data
1. In the Applications Manager, go to Activities > Requests.
2. Select AW_TELEMETRY_REPORT.
3. Click Request.
4. Click Submit & close.
The task starts running, and you can find it under Backlog.
 Applications Manager 9.4.1

Send the report file

1. Once the populate job is finished, the AW_TELEMETRY_REPORT task will appear under History.
2. Right-click the task and then click Output Files. The Task Details window appears.
3. Look for a file that starts with the letter b. For example, b.434.00. This file is also known as the report file.
4. Double-click the file name, The File Viewer window appears.
5. Click the Save icon to save the file on your computer.
6. Send this file to Broadcom support.

13 Documentation Legal Notice

Information about the documentation legal notice.
This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter
referred to as the “Documentation”) is for your informational purposes only and is subject to change or withdrawal
by Broadcom at any time. This Documentation is proprietary information of Broadcom and may not be copied,
transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of
Broadcom.
If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise
make available a reasonable number of copies of the Documentation for internal use by you and your employees
in connection with that software, provided that all Broadcom copyright notices and legends are affixed to each
reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the
applicable license for such software remains in full force and effect. Should the license terminate for any reason, it
is your responsibility to certify in writing to Broadcom that all copies and partial copies of the Documentation have
been returned to Broadcom or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, BROADCOM PROVIDES THIS DOCUMENTATION “AS
IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT
WILL BROADCOM BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR
INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS,
LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF BROADCOM IS
EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement
and such license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is Broadcom Inc.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject
to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section
252.227-7014(b)(3), as applicable, or their successors.
Copyright © 2005-2022 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its
subsidiaries. All trademarks, trade names, service marks, and logos referenced herein belong to their respective
companies.