7
Oracle Applications Jobs

The job tasks and job scheduling services of the Oracle Enterprise Manager console allow you to automate standard and repetitive tasks, such as executing a SQL script or executing an operating system command. The Management Pack for Oracle Applications includes job tasks that can be configured to bring a concurrent manager up or down. The pack also includes job tasks that can be configured to trigger automatically as fixit jobs for a particular event. Jobs can be scheduled for specific times or time intervals allowing the administrator to proactively monitor and correct problems.

This chapter describes each of the jobs included with the Management Pack for Oracle Applications. For more information on submitting or scheduling jobs, see the Oracle Enterprise Manager Administrator's Guide.

Setting Concurrent Manager Node Credentials

Prior to using Oracle Applications Jobs, you must set the Concurrent Manager Node Credentials. This is necessary because on UNIX, all jobs executed by the Oracle Intelligent Agent are performed as the operating system (OS) user specified in the preferred credentials for that node. This may present an Oracle Applications administrator with a problem if the APPL_TOP for the Concurrent Processing server is owned by an OS user, such as applmgr, which is different from the OS user, oracle, which is needed to perform database operations.

The following are suggestions for how to work around this problem:

• Create two separate Enterprise Manager users: one for performing database related activities, and another for performing Oracle Applications related activities.

  Log on to the Enterprise Manager database account and set the node credentials to the user oracle. Log out of Enterprise Manager and log back on as the Enterprise Manager Oracle Applications user. Set the node credentials to the applmgr account.

• Keep the user oracle in the preferred node credentials. Allow the ICM to be started as user oracle. All log and output directories must be writable by user oracle. The users oracle and applmgr should belong to the same group. You may need to set the umask in the .login files of these users to ensure that files created in the Concurrent Manager's environment have the appropriate group permissions.
• Keep the user oracle in the preferred node credentials. Configure the .rhosts file for applmgr so that the user oracle can rsh to the managed node as the user applmgr. Alter the concurrent manager startup script ($FND_TOP/bin/oemstart.sh, for example) to rsh as applmgr to the managed node and start the concurrent manager.

  For example, if your Intelligent Agent is on "prodapps.acme.com" add the following line to the .rhosts file for the user "applmgr":

  prodapps.acme.com oracle

  The concurrent manager startup script should then read:

  rsh -l applmgr prodapps.acme.com sh -c "\".$1;startmgr sysmgr=$2\""
  
  

• Change the oemstart.sh script to be set-user-id (suid), owned by the APPL_TOP owner applmgr.

Job Descriptions

The job tasks for Oracle Applications are:

• "Concurrent Manager Shutdown"
• "Concurrent Manager Shutdown (for V8.1.6 and Earlier Agents)"
• "Concurrent Manager Startup"
• "Concurrent Manager Startup (for V8.1.6 and Earlier Agents)"
• "Kill Locking Session"
• "Kill Locking Session (for V8.1.6 and Earlier Agents)"
• "Load Data into Concurrent Processing Tuning Assistant"

  Note: The jobs for release 8.1.6 and earlier targets are included for backward compatibility purposes. It is highly encouraged that you upgrade to the new jobs because the old jobs may not be supported in future releases of the Management Pack for Oracle Applications.

Concurrent Manager Shutdown

The Concurrent Manager Shutdown job task shuts down the Internal Concurrent Manager (ICM), in the mode specified by the user. This job requires an Agent that is release 8.1.7 or higher.

When configured in the abort mode, the job shuts down the ICM regardless of the existing state of the queues.

When configured in the stop mode, the job waits until current requests are processed and completed before stopping the ICM.

Parameters

1. Stop
2. Abort

Choose the Stop mode if you would like to bring down the ICM graciously. Choose the Abort mode if you would like to bring down the ICM immediately, regardless of the state of the concurrent request queues.

Output

1. Completion status of the job
2. Name of user who registered the job
3. Name of target database

User Action

If the job fails, check the ICM log file for details. If the environment variable APPLCSF is set, the ICM log file will be located in $APPLCSF/$APPLLOG. Otherwise, the ICM log will be located in $FND_TOP/$APPLLOG.

Concurrent Manager Shutdown (for V8.1.6 and Earlier Agents)

The Concurrent Manager Shutdown job task shuts down the Internal Concurrent Manager (ICM), in the mode specified by the user.

When configured in the abort mode, the job shuts down the ICM regardless of the existing state of the queues.

When configured in the stop mode, the job waits until current requests are processed and completed before stopping the ICM.

Parameters

1. Stop
2. Abort

Choose the Stop mode if you would like to bring down the ICM graciously. Choose the Abort mode if you would like to bring down the ICM immediately, regardless of the state of the concurrent request queues.

Output

1. Completion status of the job
2. Name of user who registered the job
3. Name of target database

User Action

If the job fails, check the ICM log file for details. If the environment variable APPLCSF is set, the ICM log file will be located in $APPLCSF/$APPLLOG. Otherwise, the ICM log will be located in $FND_TOP/$APPLLOG.

Concurrent Manager Startup

The Concurrent Manager Startup job task starts the Internal Concurrent Manager (ICM). This job task can be configured as a fixit job to be associated with the Concurrent Manager UpDown event test to automatically start up the Concurrent manager (ICM) when it goes down. This job requires an Agent that is release 8.1.7 or higher.

Parameters

1. Queue Size: The duration of time between worker quantity checks (checks for number of active workers). The unit of time is process monitor checks. Default is 1.
2. Sleep Time: The number of seconds that the concurrent manager should wait between checks for new requests. Default is 60.
3. Pmon: The duration of time between process monitor checks (checks for failed workers). The unit of time is concurrent manager iterations (request table checks). Default is 5.
4. Restart: The concurrent manager will attempt a restart after an abnormal termination. Default value is Not Checked.
5. Diag: Determines if diagnostic output should be produced regularly by all concurrent managers. This should be off (unchecked) under most circumstances, since much information (and thus large log files) is produced. Default value is Not Checked.

Output

1. Completion status of the job
2. Name of user who registered the job
3. Name of target database

User Action

If the job fails, check the ICM log file for details. If the environment variable APPLCSF is set, the ICM log file will be located in $APPLCSF/$APPLLOG. Otherwise, the ICM log will be located in $FND_TOP/$APPLLOG.

Concurrent Manager Startup (for V8.1.6 and Earlier Agents)

The Concurrent Manager Startup job task starts the Internal Concurrent Manager (ICM). This job task can be configured as a fixit job to be associated with the Concurrent Manager UpDown event test to automatically start up the Concurrent manager (ICM) when it goes down.

Parameters

No parameters are required.

Output

1. Completion status of the job
2. Name of user who registered the job
3. Name of target database

User Action

If the job fails, check the ICM log file for details. If the environment variable APPLCSF is set, the ICM log file will be located in $APPLCSF/$APPLLOG. Otherwise, the ICM log will be located in $FND_TOP/$APPLLOG.

Kill Locking Session

The Kill Locking Session job task is intended to be used as a fix-it job for the following Oracle Applications Advanced Event Tests:

• ICM Waiting on a Lock
• CRM Waiting on a Lock

It is rare for a concurrent program to lock out the ICM or CRM for an excessive amount of time. This job will most likely trigger for a form session that is out of control.

When configured as a fixit job for the previously mentioned event tests, the session preventing ICM or CRM from continuing would automatically be deleted. This job requires an Agent that is release 8.1.7 or higher.

Parameters

No parameters are required.

Output

User will be informed if the job succeeds.

User Action

If the job fails, check your user privileges to make sure you have the rights to kill the session.

Also, check the ICM log file for details. If the environment variable APPLCSF is set, the ICM log file will be located in $APPLCSF/$APPLLOG. Otherwise, the ICM log will be located in $FND_TOP/$APPLLOG.

Kill Locking Session (for V8.1.6 and Earlier Agents)

The Kill Locking Session job task is intended to be used as a fix-it job for the following Oracle Applications Advanced Event Tests:

• ICM Waiting on a Lock
• CRM Waiting on a Lock

It is rare for a concurrent program to lock out the ICM or CRM for an excessive amount of time. This job will most likely trigger for a form session that is out of control.

When configured as a fixit job for the previously mentioned event tests, the session preventing ICM or CRM from continuing would automatically be deleted.

Parameters

No parameters are required.

Output

User will be informed if the job succeeds.

User Action

If the job fails, check your user privileges to make sure you have the rights to kill the session.

Also, check the ICM log file for details. If the environment variable APPLCSF is set, the ICM log file will be located in $APPLCSF/$APPLLOG. Otherwise, the ICM log will be located in $FND_TOP/$APPLLOG.

Load Data into Concurrent Processing Tuning Assistant

The Oracle Concurrent Processing Tuning Assistant (CPTA) is a utility that allows you to examine historical processing information about Oracle Concurrent Processing requests and concurrent managers. Its reports are limited by the amount of information stored in FND tables. Since, in a production system, these tables are purged on a regular basis, there is a need to keep the data in a new repository schema. When you run this job, data will be uploaded from the Applications schema FND tables into the new repository schema. Data will then be aggregated into new tables. This accelerates the processing of the reports.

The repository schema can reside in any Oracle database. Given the potentially massive amount of data that can be stored in this repository, Oracle recommends that you do not use the Oracle Enterprise Manager repository schema for this purpose.

In the first execution of the 'Load Data into Concurrent Processing Tuning Assistant' job, approximately 20% of the data in the FND tables is copied to the new repository schema. Every consecutive execution of the job copies only the records added since the previous copy. The repository will continue to grow in proportion to the load on your Applications database.

Parameters

1. User Name: User name for the Repository Schema. This name must be an existing database user name.
2. Password: Password for the user name.
3. Host: Host name for the database where the Repository Schema resides.
4. Port Number: Port number for the database where the Repository Schema resides.
5. SID: Database system identifier for the database where the Repository Schema resides.
6. Purge Policy: Indicates that, when the job runs, data which is older than the number of days entered in this field will be purged from the repository. If the field is left blank or you enter 0, then the data is not purged.