Defining Concurrent Programs and Requests

Overview of Concurrent Programs and Requests

A concurrent program is an executable file that runs simultaneously with other concurrent programs and with online operations, fully utilizing your hardware capacity. Typically, a concurrent program is a long-running, data-intensive task, such as posting a journal or generating a report.

Standard Request Submission (SRS) is an Oracle E-Business Suite feature that allows you to select and run your concurrent programs from a single, standard form (Submit Request) or window (Schedule Request). Requests to run concurrent programs are called concurrent requests.

There are two main ways to group concurrent programs. Request sets are defined to run several concurrent program in a single request. Request groups are used to control access to concurrent programs via responsibilities. Both request sets and request groups are discussed in later sections

Related Topics

Organizing Programs into Request Sets

System Administrator Request Set Privileges

Organizing Programs into Request Groups

Copying and Modifying Program Definitions

Running Reports and Programs, Oracle E-Business Suite User's Guide

Controlling Access to Concurrent Programs and Limiting Active Requests for a User

You can restrict users' access to submit and view concurrent requests.

Controlling Access to Concurrent Programs with Request Security Groups

Note: This method is used in releases prior to Release 12.

A request security group is a collection of reports or concurrent programs. A System Administrator defines request security groups in order to control user access to reports and concurrent programs. Only a System Administrator can create a request security group.

Controlling Access to Concurrent Programs using Role-Based Access Control (RBAC)

RBAC allows administrators to have more granular control in securing data related on concurrent programs and requests.

Submitting Requests

Administrators can assign individual programs/sets, all programs/sets in a request group, programs/sets belonging to one or more applications, and so on, either to the user directly or to a role that can then be assigned to one or more users. For more information on RBAC, see: Overview of Access Control with Oracle User Management, Oracle E-Business Suite System Administrator's Guide - Security.

If applications are included in the request groups, all programs/requests sets that are created in these applications will also be automatically included. Please note that request submission applies to both programs and request sets.

The following types of "instance sets" can be used for assignment (but administrators can create new instance sets based on their needs):

To enable this functionality, the following are seeded:

To grant access to a request security group to a role, follow these steps:

  1. Define your role (User Management responsibility).

  2. Define your request security group (System Administrator responsibility).

  3. Define your grant (Functional Administrator responsibility).

    1. Enter a Name and Description (optional) for the grant.

    2. Enter the Security Context for the grant.

    3. Under Data Security, choose "Concurrent Programs" or "Request Sets" as the object. Click Next.

    4. For the Object Data Context, select "Instance Set" for the Data Context Type. Choose either "Programs that can be accessed" or Request Sets that can be accessed" as appropriate. Click Next.

    5. Review the Instance Set information. Under Instance Set Details, enter the request group and its application. Specifically, enter the request group name as Parameter 1 and the application short name as Parameter 2.

    6. Choose "Request Operations" as the permission set under "Set". Click Next.

    7. Review the grant information and save your work.

Note that there are two seeded grants for all users to account for request group assignments that already exist for legacy responsibilities. These are:

Viewing Requests

You can control users' access to viewing requests with RBAC.

Note: In previous releases, the Concurrent: Report Access Level profile was used to control privileges to report output files and log files generated by a concurrent program. This profile is no longer used.

Seeded "instance sets" allow administrators to grant:

to another user (or a group of users - via a role).

System administrators can create new "instance sets" based on their needs. They can grant access to requests (of a particular program/set) submitted by all users to a specific set of users. For example, say a given application's administrators group want to track all requests of a particular type or program submitted by business users. Then the following approach, to grant specific programs' requests to a group of users, can be used:

  1. Create an instance set that selects all the requests belonging to the particular program irrespective of which user submitted it.

    For example,

    &TABLE_ALIAS.request_id in
    ( select cr.request_id
      from fnd_concurrent_requests cr, fnd_concurrent_programs cp
      where cr.concurrent_program_id = cp.concurrent_program_id
      and cr.program_application_id = cp.application_id
      and cp.concurrent_program_name = &GRANT_ALIAS.PARAMETER1)

    If you want to grant access to a set of programs instead of a single program, '&GRANT_ALIAS.PARAMETER1' can be replaced with a subquery that returns all the programs in a particular request group.

  2. Create a grant to grant this instance set to (an existing) role, for example, "<Application> Administrator" role, and assign the program name to grant. Use the "Concurrent Requests" data object in creating this grant.

  3. Ensure that the role is assigned to all users that should have access to these requests.

Limiting Active Requests by a User

As System Administrator you can limit the number of requests that may be active (status of Running) for an individual user. This ensures that a user cannot monopolize the request queue. For example, if a user with an Active Request Limit of 5 submits 20 requests, only 5 requests will be run at the same time. The remaining requests will be run when the number of active requests for the user drops below 5. Use the Profile Options window to set the Concurrent: Active Request Limit profile. To set a global limit for all users, set this option at the site level. You can then modify limits for individual users by setting this profile option at the User level.

Organizing Programs into Request Sets

Reports and concurrent programs can be assembled into request sets.

Request sets define run and print options, and possibly, parameter values, for a collection of reports or concurrent program. End users, with the appropriate privileges, and System Administrators can define request sets. A System Administrator has request set privileges beyond those of an end user. Request sets can be run from Forms-based applications and HTML-based applications.

Request sets are a quick and convenient way to run several reports and concurrent programs with predefined print options and parameter values. Request sets group requests into stages that are submitted by the set. The order in which the stages are submitted is determined by the status of previous stages.

Request sets can also be used by a System Administrator to customize access to reports and concurrent programs. Using request sets, a System Administrator can:

As System Administrator, you have privileges beyond those of your application users, including a privileged version of the Request Set window.

Defining Request Sets

You can run the same set of concurrent requests regularly by defining a request set, and then submitting the request set from the Submit Requests form.

As System Administrator, you can include any Standard Request Submission report or concurrent program in the request sets you define. When end users define a request set, they can only select from reports and programs that belong to their responsibility's request security group.

Use the Request Set form to create and edit request sets.

Request Set Stages

This section describes how request set stages are defined and organized.

Organizing Request Sets into Stages

Request sets are divided into one or more "stages" which are linked to determine the sequence in which requests are run. Each stage consists of one or more requests that you want to run in parallel (at the same time in any order). For example, in the simplest request set structure, all requests are assigned to a single stage. This allows all of the requests to run in parallel.

Request Set with a Single Stage

the picture is described in the document text

To run requests in sequence, you assign requests to different stages, and then link the stages in the order you want the requests to run.

Request Set with a Sequence of Stages

the picture is described in the document text

The concurrent manager allows only one stage in a request set to run at a time. When one stage is complete, the following stage is submitted. A stage is not considered to be complete until all of the requests in the stage are complete.

One advantage of using stages is the ability to run several requests in parallel and then move sequentially to the next stage. This allows for a more versatile and efficient request set.

Request Set with Multiple Requests Running in Parallel within a Stage

the picture is described in the document text

Using Stage Status

Like request sets and concurrent requests, stages can complete with different statuses. Each stage can complete with a status of Success, Warning, or Error. You can use these completion statuses to structure your request set, by defining which stage will follow the current stage based on its completion status. For example: a request set always begins with Stage 1. If Stage 1 completes with the status Success, then the Success link is followed, and Stage 2 is submitted. After Stage 2 completes, the set ends. If Stage 1 completes with Warning, then the Warning link is followed, and Stage 3 is submitted. After Stage 3 completes, the set ends. If Stage 1 completes with Error, then the Error link is followed, and Stage 4 is submitted. After Stage 4 completes, the request set ends.

Request Set Using Stage Statuses

the picture is described in the document text

In this example, the stage status is determined using the Standard stage function. The Standard stage function uses the statuses of the requests within the stage to calculate the status for the stage. If all of the requests in a stage complete with a status of Success, then the status for the stage is Success. If one or more requests complete with a status of Error, then the status of the stage is Error. For a stage's status to be Warning, one or more of the requests must have a status of Warning, and no request may have a status of Error.

Linking of Stages

There are no restrictions on linking stages within a request set. Any stage may be linked to any other stage, including itself. Two or more links can point to the same stage. For example, Stage 1 can link to Stage 2 if the completion status of Stage 1 is Success or Warning, and link to Stage 3 if the status is Error.

Request Set with Multiple Links to Stages

the picture is described in the document text

You determine the end of a request set by not specifying a followup stage for each completion status. You can end a request set after any stage in the request set. When any stage completes with a status that does not link to another stage, the request set ends.

You can use the linking of stages to control your request set. In previous releases you had three options: run in parallel, run sequentially, and run sequentially but abort on Error. All of these are easy to recreate using the request set wizard. You can use the Request Set Wizard button in the Request Set window to start the wizard. The wizard takes your input and creates the request set as follows:

Variable Description
Run in Parallel Creates one stage containing all of the requests you wish to run in parallel.
Run Sequentially Creates a separate stage containing the request or requests for each step in the sequence and link in the appropriate order.
Run Sequentially but abort on Error Sets up your sequence the same as it did for Run Sequentially, but when it links the stages, it does not enter a follow up stage as a link in the Error completion status field.

Stage Evaluation Function

The completion status of a stage is determined by a predefined function. The Oracle E-Business Suite Standard Stage Evaluation function uses the completion status of the requests it contains. Use this function to determine the status of a stage.

Request Set Completion Status

When a stage completes with a status for which there is no link defined, the request set ends. The completion status for the request set is determined by one of the following methods:

Printing Request Sets

On a report-by-report basis, you can select a different printer for each report in a request set. When you define a request set, print options, such as the printer a report is sent to, are saved so you do not have to specify them again when you run the request set.

Important: If a printer is defined for a concurrent program using the Concurrent Programs form, then that value cannot be updated, either by a user profile option setting, a request set definition, or when running the program or request set.

Note: Defining a printer for a request set concurrent program (for example, Request Set Payables Aging Reports) in the Concurrent Programs form has no effect; the printer definition is not referred to.

Holding Request Sets

In some circumstances, such as when a request set has a large number of stages and takes a long time to execute, administrators may want to yield a request set to higher priority requests. By utilizing the Hold Request Set feature, users can place a running request set on hold and effectively control the execution of request set stages.

The Hold and Remove Hold buttons are available on the OAM View Running Requests page. To hold a request set, simply select the request set and click the Hold button. Click Remove Hold when you want the request set to continue executing.

Request Sets as Concurrent Programs

When you define a request set or a stage within a request set that allows incompatibilities, a concurrent program is created to run the requests in your request set according to the instructions you enter.

All concurrent programs that run request sets are titled Request Set <name of request set>, and programs that run request set stages are titled Request Set Stage <name of request set stage>. In the Concurrent Programs form, to query request set or request set stage concurrent programs on the basis of a program's name, enter the following in the Name field:

Request set and request set stage concurrent programs create log files documenting the execution of the request set or stage. Each report or concurrent program within a request set or stage also creates its own log file.

Note: The recorded actual start time for a request is the start time the request's status is changed to "Running". A request may need to wait to start until it has necessary information from child process(es).

When you run a request set that allows incompatibilities, you submit a request to run the concurrent program that defines the request set. The request set concurrent program submits a request set stage concurrent program. The request set stage concurrent program submits the requests for the individual programs and reports within the stage. A request to run the request set concurrent program or the request set stage concurrent program is a Parent request, while the requests to run the programs and reports are Child requests.

You can review the status of a request set and the programs it contains using the Concurrent Requests form. The following table displays information pertaining to request sets in the Running phase.

Status Description
Paused Parent request pauses for all its Child requests to complete. For example, a request set stage pauses for all reports in the stage to complete.
Resuming All requests submitted by the same Parent request have completed running. The Parent request resumes running.

Modifying Request Sets

A request set can only be modified by its owner or by a System Administrator. To make modifications, query the request set you want to modify in the Request Set window.

Note: If you wish to retain modifications to request sets provided by your Oracle application during upgrades, you must rename or recreate the request set using a different name before you upgrade. If you modify a predefined request set without changing the name, your modifications are overwritten when you upgrade your Oracle E-Business Suite.

Creating Request Sets

Follow this procedure to create a request set:

  1. Navigate to the Request Set window.

  2. Enter a Name for your request set.

  3. Enter a Set Code for your request set. This name is used internally to reference your request set.

  4. Enter the Application with which you want to associate your request set.

  5. Enter a Description of your request set if you like.

  6. The Owner field defaults to your username and can only be changed by your system administrator.

  7. Enter the Active Dates From and To fields to define an effective period when you and others can run the request set. If the current date is outside the range you define, the request set will not be available in the Submit Requests window. Note that the request set will not be available on the date specified in the To" field.

  8. Check the Print Together check box to send all your requests to the printer together when they complete, or uncheck the check box to send each request one at a time to the printer as it completes.

  9. Check the Allow Incompatibility check box to allow your system administrator to specify programs that this request is incompatible with (may not run with). Leave Allow Incompatibility unchecked to specify that this request set may run with all other concurrent requests or request sets.

  10. Choose Define Stages or Link Stages if you have finished defining your stages.

Defining Stages

Follow this procedure to define stages:

  1. The value for the Display Sequence is defaulted in sequence as you enter your stages. You may change the display order of the stages by modifying this field.

  2. Enter a Name for the stage.

  3. Enter a Description of your stage if you like.

  4. Enter a Stage Code for the stage. This code is used internally to reference the stage.

  5. In the Function field of the Function region, use the List of Values to select a function. The default value for this field is the Standard Stage Evaluation function. This function bases its completion status on the normal completion status of the requests it contains. Other functions may be provided by your Oracle product. For a description of these functions, refer to the user's guide for that product.

  6. Use the "The Return Value of this Stage Affects the Set Outcome" check box if you want to ensure that the request set's completion status is equal to the completion status of this stage.

    Note: If you choose this check box for more than one stage, the completion status of the request set will equal the completion status of the last of these stages to run within the set.

  7. Use the Allow Incompatibility check box to allow your system administrator to specify programs that this stage is incompatible with (may not run with). Leave Allow Incompatibility unchecked to specify that this stage of the request set may run with all other concurrent requests or request sets.

  8. Choose Requests.

Stage Requests Window

In the Stage Requests window you define which requests you want to include in the stage.

  1. Select the report or program you want to include in your request set. A description of the request you choose and its associated application appears in the Description and Application fields.

    The list of requests you can choose includes the requests that your responsibility's request group lets you access from the Submit Requests form.

  2. Use the Allow Stage Function to Use This Program's Results check box to indicate which programs or reports should be included.

  3. The Print Options region reflects the options for the current request. Specify the number of Copies of output to print, the Style to print, the Printer to print to, and whether to save the output to an operating system file.

    Standard Request Submission saves these options so you do not have to specify them again when you run the request set. If you do not wish to specify these options for each request when you define the set, Standard Request Submission uses the values of your personal profile options as the default when you submit the request set. See: Concurrent Processing User Profile Settings, Oracle E-Business Suite System Administrator's Guide - Maintenance.

    Note: Some requests may have a required Style or Printer that you cannot change.

  4. When you are done with the Print Options, choose Parameters to display the Request Parameters window.

Request Parameters Window

The Request Parameters window lets you customize the parameter values of a specific request in a request set. The fields at the top of the Request Parameters window list general information about the current request set and the request for which you can customize the parameter values. The multi-row portion of the window lists the parameters for that request.

  1. The Sequence field displays the order in which each request parameter appears when you run the request in the Submit Requests window (lower numbers appear before higher numbers). Only your system administrator can change a parameter's order.

  2. The Prompt field is a display-only field that shows the request parameter's prompt.

  3. Check the Display check box to specify that you can see a request parameter at submission time, or uncheck the check box to specify that a parameter should not be displayed at submission time.

  4. Check the Modify check box to specify that you can insert or change the value for a request parameter at submission time, or uncheck the check box to specify that a parameter cannot be changed at submission time.

  5. Use the Shared Parameter field to set a default value for a parameter that occurs in more than one report or program of a request set. Once you enter the same parameter label in the Shared Parameter field for each occurrence of the same parameter, the value that you assign to the first occurrence of the parameter becomes the default value for all subsequent occurrences of the parameter. The shared parameter label simply enables you to set an initial default value for all occurrences of the same parameter so you can avoid typing the same value all over again for every occurrence of the parameter.

    For example, suppose you define a request set that includes three reports, and all reports include a parameter called “Set of Books". You want the “Set of Books" parameter to default to the same value in all reports. To accomplish this, enter a label called “Book" in the Shared Parameter field for the first occurrence of this parameter. You can also assign a value in the Default Value field of this parameter now, or wait until you run the request set to assign a default value when the parameter first appears. Enter the label “Book" in the Shared Parameter field of all other occurrences of the “Set of Books" parameter in your request set. When you submit this request set from the Submit Requests window, every parameter that you label “Book" defaults to the value you assign to the first occurrence of the “Set of Books" parameter.

    Important: Note that if you later change the value of a parameter that contains a shared parameter label, you change only the value for that instance of the parameter, and not the value for all other occurrences of that labelled parameter.

    We recommend that if you make a parameter with a shared parameter label modifiable, that you also display the parameter so you can always see what the parameter's current value is. This helps reinforce the understanding that a later value change to one labelled parameter cannot propagate a value change to all other similarly labelled parameters.

  6. Optionally enter a Default Type and Value for the parameter.

  7. Save your work.

  8. Go back to the Stage Requests window and repeat Steps 9 through 11 to add more requests to the request set stage.

    You can select a request more than once if you want to run the same request with different default parameter values.

  9. To start a new stage, return to the Stage window and choose New Record from the File Menu.

Linking Stages

Follow this procedure to link stages:

  1. Enter the Start Stage. The stage you enter here is the first stage submitted for the request set.

  2. Enter the stages you want to run following the first stage in the Success, Warning, and Error columns. To ensure that a particular stage follows the preceding stage regardless of the completion status, enter the desired stage in all three columns. To stop the request set if a stage ends in Error, leave the Error column blank. Any time you do not specifically indicate which stage should follow for a completion status, the request set will exit on that completion status.

    In the example shown in the table below, the request set will always exit if any stage returns a completion status of error. In addition, stages C and D will terminate the request set regardless of their completion status. If Stage A returns a status other than Error, Stage B will be submitted. Finally, when Stage B completes with a status of Success, it is followed by Stage C, or if the status is Warning, Stage D will follow.

  3. Choose Done.

The following table shows an example of linking stages as in step 2 above:

Display Sequence Name Success Warning Error
1 Stage-A Stage-B Stage-B  
2 Stage-B Stage-C Stage-D  
3 Stage-C      
4 Stage-D      

Restarting Request Sets

If a request set completes with a status of Error, the Restart button, on the Oracle Applications Manager - View Completed Requests page is enabled. The system also automatically captures, records, and saves the information of the first stage that fails so that when the user clicks on the Restart button the request set can restart from that point.

Once the stage has been identified, the request set program submits the stage program in resubmit mode. In this mode, the program looks at the same stage from the previous run and determines which programs need to be rerun, (only those that ended in error), and runs those programs. If this stage completes successfully or has a Warning status, the system proceeds to the next stage using the normal mechanism of restarting the request set program.

Note: Users may restart a request set multiple times. The logs for each stage and individual programs are maintained independent of the number of runs as each stage and program submission generates a new request. However, the logs and associated files for a request set are rewritten each time the set is restarted.

Related Topics

Overview of Concurrent Programs and Requests

Request Sets and Owners

There are significant differences between end user and System Administrator privileges when defining or editing request sets.

End users own the request sets they create

An end user can create a request set by selecting reports, other request sets, or concurrent programs that are part of the report security group assigned to his or her responsibility.

When an end user creates a request set, the user automatically becomes the “owner" of the request set. Ownership is identified by the person's application username.

End users use the Request Set form to create a new request set, or to query and update any request sets they own. End users can only edit request sets they own.

We sometimes refer to a request set that an end user owns as a private request set. Private request sets are not automatically added to a request security group. That is, other users cannot access your private request sets using the Submit Requests window unless the System Administrator assigns that request set to a request security group.

Request sets owned by an end user are always available to that user, regardless of what responsibility the user is operating under. However, a standard submission form customized to display only reports in a request group using a code does not display private request sets.

When a user signs on to Oracle E-Business Suite, the user can run requests, request sets, and concurrent programs included in:

End User Benefits from Private Request Sets

Private request sets offer two main benefits to end users:

  1. The request sets that users own are always available to them, regardless of which responsibility they are working under.

  2. Users can create as many request sets as they want without adding request set choices to the list of standard submission concurrent programs that other users must select from.

System Administrator Request Set Privileges

As System Administrator, you can:

After you define a request set, you can assign a user to be its owner if you want the user to be able to run or edit this request set from any responsibility. Request sets without an owner cannot be edited or updated by any end users. In this way, you can guarantee print options and report parameters for a request set. You can also later edit the request set to remove or change its ownership properties.

Other users can also run a request set if you, as System Administrator, assign the request set to their responsibility's request security group. If you do not assign a request set to a request security group, then only the owner can run the request set. In this way, you can grant access to reports and concurrent programs on a user-by-user basis.

Request Security Groups, Request Sets, and Reports

As System Administrator you can add any request set, including private request sets, to a request security group. This allows you to provide members of a responsibility access to reports and programs outside their request security group.

Request set editing and report viewing privileges are different for reports that belong to a user's request security group than they are for reports that are not in the user's request security group.

System Administrator Benefits from Request Sets

Request sets offer three main benefits to System Administrators:

  1. Request sets offer a means of controlling access to concurrent programs on a user-by-user basis.

    By defining a request set, assigning it an owner, and then not assigning the request set to any request security group, the reports and programs in the request set are only available to the owner.

  2. By leaving the Owner field blank, System Administrators can create request sets whose individual programs and parameters cannot be edited or updated by end users.

    Only a System Administrator can edit a request set that has no owner.

  3. System Administrators can provide members of a responsibility access to reports and programs outside their request security group.

    By defining a request set that contains reports or programs not in a request security group, and assigning that request set to the request security group, users can be granted run, but not edit privileges for selected reports or programs.

Request Set Incompatibilities

A request set is actually a concurrent program that submits requests to run each program in the request set. You can allow incompatibility rules to govern your request set so that the request set does not run at the same time as other reports or concurrent programs. You can also apply these rules to the stages that make up the request set.

Use the Concurrent Programs form to query the request set concurrent program and list those programs, and/or stages you want to define as incompatible with your request set. See: Concurrent Programs.

All concurrent programs that run request sets are titled Request Set <name of request set>. In the Concurrent Programs form, if you query a request set concurrent program on the basis of the program's name, you must enter in the Name field the words:

"Request Set" before the name of a concurrent program

"Request Set %" to perform a query on all request set programs

When you list a program as incompatible with your request set, the program will not run simultaneously within the same conflict domain as the request set or any of the reports within the set. See: Defining Program Incompatibility Rules.

Related Topics

Overview of Concurrent Programs and Requests

Defining Program Incompatibility Rules

Concurrent Programs

Sharing Parameters in a Request Set

Parameters, also referred to as arguments, are values that define aspects of a program's execution. You can share a parameter and its entered value among some or all of the requests in your request set.

You identify a parameter as shared by giving it a label. Then, for each concurrent program in your request set, you can assign the same label to a parameter for that program. Among the programs in your request set, the parameters for each program share or accept a common value.

The first time you enter a value for any of the shared parameters, that value becomes the shared parameter's value. This is useful, because you only have to enter a value once, rather than for each program in the request set.

Behavior of Shared Parameters

Selecting a value for a shared parameter provides a default for subsequent occurrences of the parameter. Changing a shared parameter's value provides a new default for subsequent occurrences of the parameter, but does not affect prior requests in the set.

Once all the shared parameters contain values, changing the value for a shared parameter has no effect on the other shared parameters.

Important: Do not hide shared parameters. Do not set shared parameters to Display = No (which prevents modifying the value) or Modify = No. This prevents updates to shared parameters, which are not propagated to other reports in the set, from generating unwanted inconsistencies.

Example - Shared Parameter Value

We've created a request set containing two reports, a Concurrent Programs Report and the Concurrent Program Details Report. The two reports and their parameters are listed in the table below:

REPORT PARAMETERS
Concurrent Programs Report Application Name
Concurrent Program Detail Report Application Name, Program

We identify the parameter Application Name as a parameter shared between the two reports. We want to enter a value only once, that is, when the Report Parameters window appears for the first report in the set, requiring us to enter Application Name.

To identify a shared parameter, we give it a name, in this example, applname, and enter it as a Shared Parameter for each report.

the picture is described in the document text

the picture is described in the document text

Related Topics

Overview of Concurrent Programs and Requests

Control the Behavior of Request Parameters

Concurrent Programs

Request Sets Report

This report documents request set definitions, including the set's owner, program incompatibilities, as well as printer and print style information. Use this report when defining or editing request set definitions.

Report Parameters

None.

Report Headings

The report headings provide you with general information about the contents of the report.

Related Topics

Overview of Concurrent Programs and Requests

Organizing Programs into Request Sets

Concurrent Programs Report

Organizing Programs into Request Groups

This essay explains how you can organize your applications programs and reports into request groups. It presents the following topics:

Defining a Request Group

When defining a request group, you can include:

Two Types of Request Groups

A request group is used by Oracle E-Business Suite at two different levels:

  1. Responsibility level

    When a request group is assigned to a responsibility, it is referred to as a request security group, and it defines the reports, request sets, and concurrent programs that a user, operating under that responsibility, can select from the Submit Requests Window.

  2. Form level

    When a request group is assigned a code, that code can be passed as a parameter to the Submit Requests Window. The code helps define the function that calls the Submit Requests Window.

    The list of values for that unique Submit Requests Window lists the reports, request sets, and concurrent programs in the request group.

Request Security Groups

When a request group is assigned to a responsibility, the request group is referred to as a request security group. Any user signed on under a responsibility can run the reports and concurrent programs contained in their responsibility's request security group.

The Submit Requests standard submission form displays a list of all the reports and programs in the current responsibility's request security group.

Related Topics

Using Codes with Request Groups

Customizing the Submit Requests Window using Codes

Report Group Responsibilities Report

Request Groups

Using Codes with Request Groups

Normally, when a menu calls the standard request submission form, that form can list the reports and concurrent programs contained in the report security group for the current responsibility.

Alternatively, you can assign a code to a request group so that a customized standard submission form only displays a list of concurrent programs contained in that particular request group. A request group code is simply an argument that is passed from a menu to a customized standard submission form. To summarize:

Related Topics

Organizing Programs into Request Groups

Customizing the Submit Requests Window

Customizing the Submit Requests Window using Codes

Request Groups

Customizing the Submit Requests Window

You can customize the Submit Request window in several ways.

Rename the Window Title

You can change the title to reflect the requests available in the window. See: Customizing the Submit Requests Window using Codes.

Restrict Requests Available to A Request Group

You can restrict the reports and programs available to those in a specified request group. See: Customizing the Submit Requests Window using Codes.

Restrict Requests to a Single Request

You can call Submit Requests form for a single request submission by passing the program/set name as parameters

The parameters window pops up on navigation to the form when called with a program/report_set name. The form exits after the user acknowledges the displayed request ID for the submitted request.

Restrict Requests To A List of Requests

You can call Submit Requests form to submit one or more requests for a single program/set by passing the program/set name as parameters

The parameters window pops up on navigation to the form and the user can submit one or more requests for the program that was passed as a parameter. Requests for other programs cannnot be submitted in this case.

Pass Parameters Used in Value Set Parameters

You can pass additional parameters to the Submit Requests form that can be referenced in the value sets to validate the request parameters.

Pass Manufacturing "ORG" Parameters

You can pass 5 ORG related parameters and refer to them in the value set. Alternatively, you can bring up a ORG LOV on navigation to the Submit Requests form that populates the ORG parameters which can be referenced in the value sets.

Complete List of All Submit Request Paramters

Below is the comprehensive list of parameters supported by the "Run Requests"/SRS form and additional information about their usage.

Customizing the Submit Requests Window using Codes

You can give the Submit Requests Window a different title, and define the form so that it allows users to select only those reports or concurrent programs belonging to a request group that you have assigned a code to. To do this, you register a form function that references the Submit Requests Window, and you pass certain arguments to the function. Then you construct your menu to include this form function. For more information, see: the Oracle E-Business Suite System Administrator's Guide: Security.

Using a Request Group Code as an argument

The following table describes the parameters passed to associate a request group with the Submit Requests Window and to customize the title of that form. Text is entered in the Parameters field of the Form Functions form.

Parameter Syntax followed by Example Explanation
REQUEST_GROUP_CODE ="Request Group Code" REQUEST_GROUP_CODE = "OE_CONC_PROGRAMS" This parameter passes the request group's code. (Required)
REQUEST_GROUP_APPL_SHORT_NAME = "Application short name" REQUEST_GROUP_APPL_SHORT_NAME = "OE" This parameter identifies the short name for the application associated with the request group. (Required)
TITLE ="Application_short_name:Message_Name" TITLE = "FND:SRS_NEWTITLE" This parameter identifies a message whose contents define the title, as well as the application short name of that message. (Optional)
LOOKUP = "Y|N" LOOKUP = "Y" This parameter indicates whether the TITLE parameter is a message name or a hardcoded string. The default value is "Y", which indicates that TITLE is a message name. (Optional)

Related Topics

Customizing the Submit Requests Window

Organizing Programs into Request Groups

Using Codes with Request Groups

Report Group Responsibilities Report

Request Groups

Report Group Responsibilities Report

This report lists those responsibilities which have access to a report or a request set. Use this report when granting access privileges to reports and request sets, either by assigning reports and request sets to request security groups, or when assigning owners to a request set.

Report Parameters

Application Name

Choose the application name associated with the report or request set.

Report Name/Request Set Name

Either choose the name of a report or request set.

Related Topics

Overview of Concurrent Programs and Requests

Organizing Programs into Request Groups

Request Groups

Defining Program Incompatibility Rules

This essay explains how you can define incompatibility rules for your concurrent programs and reports.

Incompatible and Run Alone Programs

When a concurrent program is incompatible with another program, the two programs cannot access or update the same data simultaneously.

When you define a concurrent program, you can list those programs you want it to be incompatible with. You can also list the program as incompatible with itself, which means that two instances of the program cannot run simultaneously.

You can also make a program incompatible with all other concurrent programs by defining the program to be run-alone.

There are two types of program incompatibilities, "Global" incompatibilities, and "Domain-specific" incompatibilities.

You can define a concurrent program to be globally incompatible with another program -- that is, the two programs cannot be run simultaneously at all; or you can define a concurrent program to be incompatible with another program in a Conflict Domain. Conflict domains are abstract representations of groups of data. They can correspond to other group identifiers, such as sets of books, or they can be arbitrary.

You define a concurrent program to be run-alone or to be incompatible with specific concurrent programs by editing the concurrent program's definition using the Concurrent Programs window. See: Concurrent Programs.

Program incompatibility and run-alone program definitions are enforced by the Conflict Resolution Manager (CRM).

Note: The concept of "Global" incompatibilities was introduced with Patch 2364876.

With this patch, all pre-existing incompatibilities are converted to the type Global, unless both of the programs have a conflict domain parameter registered. This may mean that if you have been using the Concurrent:Conflicts Domain profile option for your custom programs, you may need to switch the incompatibility type to "Domain-specific" to keep the expected behavior.

Also, the two user-level constraints, set by the Concurrent:Active Request Limit and Concurrent:Sequential Requests profile options, are now enforced globally across all conflict domains.

Request Sets - Incompatibilities Allowed

When you define a request set or request set stage that allows incompatabilities, you create a concurrent program that runs the reports in your request set or stage according to the instructions you entered. Using the Concurrent Programs window, when you list programs as incompatible with a request set, those programs are prevented from starting until all the reports in the set or stage have completed running.

To define incompatibility rules for a request set and request set stage:

All concurrent programs that run request sets are titled Request Set <name of request set> while all concurrent programs that run request set stages are titled Request Set Stage <name of stage>-Request Set <name of request set>. In the Concurrent Programs form, if you query a request set or stage concurrent program on the basis of the program's name, you must enter in the Name field the words:

Related Topics

Overview of Concurrent Programs and Requests

Request Set Incompatibilities

Modifying an Incompatible Programs list

Data Groups

Concurrent Programs

Concurrent Conflict Domains

If two programs are defined as incompatible with one another, the data these programs cannot access simultaneously must also be identified.

In other words, to prevent two programs from concurrently accessing or updating the same data, you have to know where, in terms of data, they are incompatible. A Conflict Domain identifies the data where two incompatible programs cannot run simultaneously.

Conflict Domains

In Oracle E-Business Suite, data is stored in database tables that belong to a particular application. Each table may also contain information used to determine what conditions need to be met to access the individual records. These conditions may consist of one or more of the following data groupings:

A conflict domain is an abstract representation of the groupings used to partition your data. There is no limit to the number of domains that can be defined, but excessive domains may hurt performance.

All programs are assigned a conflict domain when they are submitted. If a domain is defined as part of a parameter the concurrent manager will use it to resolve incompatibilities. If the domain is not defined by a parameter the concurrent manager uses the value defined for the profile option Concurrent:Conflicts Domain. Lastly, if the domain is not provided by a program parameter and the Concurrent:Conflicts Domain profile option has not been defined the 'Standard' domain is used. The Standard domain is the default for all requests.

All programs use the Standard conflict domain unless a value is defined for the profile option Concurrent:Conflicts Domain or a conflict domain is defined through a program parameter.

Each request submitted uses parameters which identify the records that it will access. For programs that are defined with incompatability rules an additional parameter (conflict domain parameter) is used. The conflict domain may be set automatically based on such variables as a login ID, set of books, or the organization the user is working in. The conflict domain parameter may in some cases be selected in the parameters field of the Submit Requests form. Once the parameter is determined the Conflict Resolution Manager (CRM) uses the domain to ensure that incompatible programs do not run simultaneously in the same domain.

Enforcing Incompatibility Rules

Concurrent managers read requests to start concurrent programs running. The Conflict Resolution Manager checks concurrent program definitions for incompatibility rules.

If a program is identified as Run Alone, then the Conflict Resolution Manager prevents the concurrent managers from starting other programs in the same conflict domain.

When a program lists other programs as being incompatible with it, the Conflict Resolution Manager prevents the program from starting until any incompatible programs in the same domain have completed running.

The figures below illustrate the role of the Conflict Resolution Manager when enforcing program incompatibility rules.

In a simple example without incompatibilities, a user submits a request to run a program. This request is then added to the request table which contains a list of requests. Managers then read requests from this table and start the associated concurrent programs.

A more complex example users may have submitted one request with incompatibility rules and another request to run a program that must be run alone. In this case these requests are added to the request table, but the Conflict Resolution Manager then checks the statuses of the requests in the table and marks which requests are ready to be run. The concurrent managers then read only the "ready" requests and start their concurrent programs.

Simple Run Program Request

the picture is described in the document text

Complex Run Program Request

the picture is described in the document text

Related Topics

Overview of Concurrent Programs and Requests

Copying and Modifying Program Definitions

Modifying an Incompatible Programs list

Concurrent Programs

Custom Concurrent Programs

This section provides information for system administrators on custom concurrent programs. It explains certain procedures and conventions for creating customized concurrent programs:

For information on creating custom concurrent programs, see the Oracle E-Business Suite Developer's Guide.

For information on setting up the development environment , see the Oracle E-Business Suite Concepts Guide.

Log and Output Filenames

Log and output files must have specific names and locations for users to review the files online.

If you use the Oracle Application Object Library routine fdpwrt() to write to files, the concurrent managers automatically name the files according to the operating system's naming conventions. This method of writing to files is completely portable. You do not have to rewrite your programs to name your log and output files differently if you port your application to another platform.

Standard Names

Standard names for log and output files are listed in the following table:

File Type Location Filename
Log Default: $<PROD>_TOP/$APPLLOG with Common Directory: $APPLCSF/$APPLLOG l<request ID>.req
Output Default: $<PROD>_TOP/$APPLOUT with Common Directory: $APPLCSF/$APPLOUT Default: <USERNAME>.<request ID> or O<request ID>.out or user.out based on value of APPCPNAM

The variable parameters shown in this table have the following values:

On UNIX platforms, the filenaming works as described in the following table:

APPCPNAM Variable Assignment in UNIX Output File Format
APPCPNAM = "REQID" o999999.out
APPCPNAM = "USER" <Applications user>.out
APPCPNAM = "USER.REQID" <Applications user>.999999
(unset or unrecognized syntax) o999999.out

In the above table, <Applications user> refers to an Oracle E-Business Suite user name and '999999' stands for a concurrent request ID.

On Windows platforms, the default format is o<request ID>.out. Setting APPCPNAM to USER on a Windows platform results in the output files having the format <user ID>.out.

Oracle Tool Concurrent Programs

If you write concurrent programs in PL/SQL, SQL*Plus, or Oracle Reports, name the program exactly as you identified it in the Execution File field of the Concurrent Program Executable window, plus an extension if necessary.

The following table lists the file extensions used for these programs and the directories where the programs should reside. (This does not apply to PL/SQL stored procedures, which are stored in the database.) The directories are under your custom application's TOP directory, $<PROD>_TOP.

If you use shared PL/SQL libraries with your Oracle Reports programs, and you want to include the libraries you write for your custom application, place the libraries in the $APPLPLS directory under your custom application's TOP directory.

Tool Extension Directory Comments
SQL*Plus and PL/SQL .sql $APPLSQL The program name is case sensitive and must exactly match the Execution file you defined with Oracle Application Object Library.
Oracle Reports .rdf $APPLREP Oracle Application Object Library looks for the .rdf file first. It uses the .rex file if it does not find the .rdf file. The program name is case sensitive and must exactly match the execution file name you defined with Oracle Application Object Library.
SQL*Loader .ctl $APPLBIN  

Pro*C Concurrent Programs

When you write a concurrent program in Pro*C, copy the skeleton programs EXMAIN.c and EXPROG.c from the directory $FND_TOP/$APPLUSR. Rename the files and globally replace SUBROUTINE_NAME with the name of your subroutine.

EXMAIN.c is the skeleton used for your spawned programs. EXPROG.c is the skeleton used for your program's logic. This module can be used to create a spawned or an immediate program. For immediate programs, you must include your copy of EXPROG.c in a program library. See below for information on building a program library.

You can use programs written with these skeleton programs as spawned or immediate concurrent programs. Spawned programs run as a separate process while immediate programs run linked in with a concurrent manager.

Important: Oracle provides information on immediate concurrent programs for backwards compatibility only. We strongly recommend that you do not create any new immediate concurrent programs. You should define your new Pro*C concurrent program executables as spawned.

Naming Your Executable File

Name your program's executable file exactly as you identified it in the Execution File field of the Concurrent Program Executable window. Put your executable file in the $APPLBIN directory under your application's TOP directory.

Building Your Program Library

Register a new program library with the Register Concurrent Program Library form and register all the programs you want to include in this library. Then enter "Yes" in the Rebuild field and commit. This creates a request to build a new catalog file called <Library Name>.c under $<PROD>_TOP/$APPLLIB$ . You should compile the <Library Name>.c file after the request completes.

Sample program libraries such as prgcat.c and prglib.c are located under $FND_TOP/$APPLUSR.

Tip: For ease of maintenance, define your concurrent program executables as spawned.

Compiling C and Pro*C Programs

Your environment for compiling custom code depends on the file $FND_TOP/usrxit/devenv. If you change this file, you should reread it by logging in again so that the changes take effect.

You compile your C or Pro*C programs into object modules using $FND_TOP/usrxit/Makefile. You then link your programs using adrelink. We do not support both compiling and linking executables using a single makefile or utility.

To compile the C program example.c, use the following syntax. In all the examples, you should run the commands from the directory in which your files are located.

$ make -f $FND_TOP/usrxit/Makefile example.o

To compile the Pro*C program proexamp.pc, use the following syntax:

$ make -f $FND_TOP/usrxit/Makefile proexamp.o

To compile the four C and Pro*C programs a.c, b.c, c.pc, d.pc (all of which are in the current directory), use the following syntax:

$ make -f $FND_TOP/usrxit/Makefile a.o b.o c.o d.o

Linking Spawned Concurrent Programs as Stand-alone Programs

If you want your spawned concurrent program to run as a stand-alone program, perform the following steps before compiling your stand-alone executable.

For custom concurrent programs you define under your custom application (as recommended), you should copy the sample.mk file from $FND_TOP/usrxit to your $<PROD>_TOP/$APPLLIB directory. Modify your copy according to the instructions contained in the file. This is the file adrelink uses to link your stand-alone executables.

Then enter the following commands.

$ . $FND_TOP/fndenv

Move to the directory in which your source files are kept.

$ cd <source_directory> 
$ make -f $FND_TOP/$APPLLIB/Makefile <source file>.o

Here, <source file> is the name of the file containing your program and <directory> is the directory where the source file is located.

You can then link your stand-alone executable and place the executable in the $APPLBIN directory under the TOP directory for your custom application:

$ adrelink force=y "<appl_short_name> <program name>"

In this relink command, <appl_short_name> is the application short name of the application your program belongs to, and <program name> is the program name.

Linking your Immediate Concurrent Program

To create a program library, you link your compiled library catalog with your program object files using an Oracle Application Object Library link procedure.

Important: Oracle provides information on immediate concurrent programs for backwards compatibility only. We strongly recommend that you do not create any new immediate concurrent programs. You should define your new Pro*C concurrent program executables as spawned.

Make sure the environment variable $LUSRLIB includes the modules that define the functions for the immediate concurrent programs and your program library. Set the $LUSRPRG variable to include the object modules of your library catalog. The file devenv in the directory $FND_TOP/$APPLUSR defines the variables $LUSRLIB and $LUSRPRG. The file fndenv executes devenv.

The files devenv and fndenv are UNIX shell scripts that set up the necessary environment variables.

We recommend that you make a copy of the working program library before linking your new immediate concurrent program library in case your new program library does not function as expected. To link your program library, execute this command from the operating system:

$ adrelink force=y "fnd UFNDLIBR"

This creates your new program library as UFNDLIBR. You can rename it, but the name of your new program library must be eight characters or less.

Testing Pro*C Concurrent Programs

You can use the following method to test your program. You must pass each argument needed by your program. To pass parameters, enter the following at the operating system prompt:

 $ <program name> <ORACLE username>/<ORACLE password> 0 Y \
[<parameter 1> <parameter 2>... ]

Instead of the Oracle username and password, you can use an Oracle E-Business Suite username and password, if the corresponding user has the System Administrator responsibility.

The program name must be uppercase and the same name that you entered in the Execution File field of the Concurrent Program Executable window. The 0 and Y arguments are required.

If any of your program-specific parameters includes spaces, enclose that parameter in double quotes. If a parameter contains a literal double quote, precede that mark with a backslash [\].

Host Language Concurrent Programs

Name your program <name>.prog, where <name> is the value you enter in the Execution File field of the Concurrent Executable window. Then make a symbolic link using your execution file name (without an extension) to fndcpesr, which is located in the $FND_TOP/$APPLBIN directory. Put your executable file and the linked file in the $APPLBIN directory under your application's TOP directory.

For example, name your custom shell script CUSTOM.prog. Create a symbolic link to fndcpesr named CUSTOM. Place both files in your $APPLBIN directory. Create your concurrent program executable using the execution file CUSTOM.

Host Program Parameters

The concurrent manager running your program puts your program name in $0, the four arguments orauser/pwd, userid, username, and request_id in $1 to $4, and your program specific parameters in $5 and beyond. Each of these arguments can be at most 50 characters.

For example, if you pass two parameters into your program, you use $5 to refer to the first parameter and $6 to refer to the second parameter.

Protecting Your Oracle User Password

In some cases, there are security concerns with passing your Oracle username and password directly to your HOST program. If you do not want the concurrent manager to pass your username/password to your program, you can have the manager pass it as an environment variable instead. Or you can pass an Oracle E-Business Suite username/password for a user with the System Administrator responsibility. Alternatively, you can not pass it at all.

First, define your concurrent program executable as a HOST program in the Concurrent Program Executable form.

To have the username/password passed as an environment variable, enter the term 'ENCRYPT' in the Execution Options field of the Concurrent Programs window when defining a concurrent program using this executable. 'ENCRYPT' signals the concurrent manager to pass the username/password in the environment variable fcp_login. The argument $1 is left blank.

If you do not want the username/password passed to the program at all, enter 'SECURE' in the Execution Options field. The concurrent manager will not pass the username/password to the program.

Success Codes

By default, a shell script returns success (status code 0). If your script traps an error, use the UNIX exit command "exit 1" to return failure (status code 1) to the concurrent manager running the program.

Log and Out Files

Use names in FCP_LOG and FCP_OUT. This way log and output/report files can be viewed online.

Testing Your Program

You should test using the <name>.prog file to make sure your script behaves correctly.

Submitting Concurrent Requests (CONCSUB)

You can test your concurrent program by submitting the program using the CONCSUB utility from the operating system.

Syntax

You can submit a concurrent request to run any concurrent program by running the CONCSUB program with the following syntax:

$ CONCSUB <APPS username>/<APPS password> \
<responsibility application short name> \
<responsibility name> \
<username> \
[WAIT=N|Y|<n seconds>] \
CONCURRENT \
<program application short name> \
<program name> \
[PROGRAM_NAME="<description>"] \
[REPEAT_TIME=<resubmission time>] \
[REPEAT_INTERVAL= <number>] \
[REPEAT_INTERVAL_UNIT=< resubmission unit>] \
[REPEAT_INTERVAL_TYPE=< resubmission type>] \
[REPEAT_END=<resubmission end date and time>] \
[NLS_LANGUAGE=<language of the request>] \
[NLS_TERRITORY=<territory of the request>] \
[START=<date>] \
[IMPLICIT=< type of concurrent request> \
[<parameter 1> ... <parameter n>]

For parameters that follow the CONCURRENT parameter and include spaces, enclose the parameter argument in double quotes, then again in single quotes. Oracle Application Object Library requires this syntax because it parses the argument string twice. For example, to pass this argument to a program:

This is an example

pass this argument through CONCSUB:

'"This is an example"'

Example

Here is an example of the command to run CONCSUB:

$ CONCSUB APPS/APPS \
SYSADMIN \
"System Administrator" \
SYSADMIN \
WAIT=N \
CONCURRENT \
FND \
FNDFMRTC \
PROGRAM_NAME='"Register Custom Tables Weekly"' \
REPEAT_INTERVAL=7 \
REPEAT_INTERVAL_UNIT="DAYS" \
REPEAT_INTERVAL_TYPE="START" \
START='"08-JUN-96 23:55:00"'
CGL
APPLSYS
ALL
CGL

Parameters

The following entries explain the required and optional parameters for submitting a concurrent program with CONCSUB. Default values are listed to the right.

Variable Description
username/ password Required. The ORACLE username and password that provides access to the data that your program uses. Alternatively, an Oracle E-Business Suite username and password for a user with the System Administrator responsibility.
responsibility application short name Required. The application short name of the responsibility whose concurrent processing options you want to use.
responsibility name Required. The name of your responsibility. If the name of your responsibility includes spaces, enclose that name in double quotes.
username Required. The uppercase username of the application user whose concurrent processing options you want to use.
WAIT Optional. A flag that indicates whether to wait for the submitted request to complete. If you leave this parameter out, the default value of N makes CONCSUB return you to the operating system prompt without waiting for your request to complete.
Set WAIT=Y to have CONCSUB check the request status every 60 seconds and return you to the operating system prompt when your request is completed. You can also enter an integer value for a number of seconds, as in WAIT=30, for CONCSUB to check for request completion every <number> seconds.

Important: Using WAIT=Y or WAIT=<number> requires that your request completes before CONCSUB returns you to the operating system. If the concurrent manager is down, your CONCSUB process waits indefinitely until the concurrent manager is started and the request completes.
CONCURRENT Required. A flag that separates the program-specific parameters from the operating system parameters.
program application short name Required. The application short name of your concurrent program.
program name Required. The uppercase name of your program. It must be the short name that you enter in the Concurrent Programs window when defining a concurrent program.
PROGRAM_ NAME Optional. A descriptive name for your program. The program field on the View Requests form displays this as the user-friendly program name. The concurrent program short name passed to CONCSUB is often hard for end users to understand, so the PROGRAM_NAME parameter allows you to pass a more easily remembered name for your concurrent program. If you do not specify a PROGRAM_NAME, the View Requests form displays the user-friendly program name specified in the Concurrent Programs window.
You may also use the PROGRAM_NAME parameter to indicate the batch that your request processes for programs that process a set of data, where there could be several requests for a given program that are active at the same time.
REPEAT_TIME Optional. The time of day to resubmit the request. The format for the time is HH24:MI or HH24:MI:SS. For example, REPEAT_TIME=14:30 resubmits your request daily at 2:30 p.m.

Important: Do not use REPEAT_TIME with other resubmission parameters except for the optional parameters REPEAT_END and START.
REPEAT_ INTERVAL Optional. The interval between resubmission (a positive integer or real number). Use this parameter along with REPEAT_INTERVAL_UNIT to specify the time between resubmissions.
REPEAT_ INTERVAL_ UNIT Optional. The unit of time used for the interval between resubmissions. The available units are MINUTES, HOURS, DAYS or MONTHS. Use this parameter along with REPEAT_INTERVAL to specify the time between resubmissions. For example, setting REPEAT_INTERVAL=12 and REPEAT_INTERVAL_UNIT=HOURS resubmits your request every twelve hours. The default value is DAYS.

Important: Do not use REPEAT_INTERVAL and REPEAT_INTERVAL_UNIT with REPEAT_TIME.
REPEAT_ INTERVAL_ TYPE Optional. Whether to time the resubmission interval from the requested start time of the request or from its completion. Set this parameter either to START or END. The default value is START.

Important: Use REPEAT_INTERVAL_TYPE only if you use REPEAT_INTERVAL.
REPEAT_END Optional. The date and time to stop resubmitting the concurrent request. Use one of the following for the format of the end date:
'"DD-MON-RR HH24:MI:SS"' (as in '"07-APR-02 18:32:05"')
or
'"DD-MON-RRRR HH24:MI:SS"' (as in '"07-APR-2002 18:32:05"')
Note that because this date format includes a space, you must enclose the date in double quotation marks and single quotation marks. You can also specify just the date:
'DD-MON-RR'
or
'DD-MON-RRRR'
NLS_LANGUAGE Optional. The NLS language for the request.
NLS_TERRITORY Optional. The NLS territory for the request.
START Optional. A start date and time for your program in this format:
'"DD-MON-RR HH24:MI:SS"' (as in '"07-APR-02 18:32:05"')
Because this date format includes a space, you must enclose the date in double quotation marks and single quotation marks. If you do not specify a start time, your program submits immediately and is processed by the next available concurrent manager. The default value is the current time.
IMPLICIT Optional. Whether to show this concurrent request on the View Requests form. Specify NO, YES, ERROR or WARNING. The value IMPLICIT=NO allows the request to appear on the View Request form. The default value is NO.
The value IMPLICIT=YES means that only the System Administrator's privileged View Concurrent Requests form displays this request. Use this value if the request is not interesting to the user.
Specify IMPLICIT=ERROR or IMPLICIT=WARNING, respectively, if you want the request to appear only if it fails or completes with warnings.
REPEAT_DAYS Optional. The number of days after which to repeat the concurrent request, calculated from the last requested start date. The number can be a positive integer or real number. For example, REPEAT_DAYS=1.5 resubmits your request every 36 hours.

Important: Do not use REPEAT_DAYS with other resubmission parameters except for the optional parameters REPEAT_END and START.

Tip: REPEAT_DAYS will become obsolete in a future release. You may therefore want to use REPEAT_INTERVAL, REPEAT_INTERVAL_TYPE and REPEAT_INTERVAL_UNIT instead of REPEAT_DAYS.
parameter 1 ... parameter n Optional. Your program-specific parameters. If a parameter includes spaces, enclose that parameter in double quotes, then in single quotes. If a parameter contains a double quotation mark as part of the argument, precede that mark with a backslash [\].

Copying and Modifying Program Definitions

These sections explain how you can copy and modify concurrent program definitions.

Warning: Do not overwrite program definitions for existing concurrent programs. Copy the program, rename it, then make any desired modifications to the new program.

Related Topics

Overview of Concurrent Programs and Requests

Copying and Renaming a concurrent program

Defining Program Incompatibility Rules

Alter Program Priority

Modifying an Incompatible Programs list

Concurrent Program Parameters

Example of modifying a program's parameters

Concurrent Programs

Warnings for Modifying Program Definitions

Copying and Renaming a concurrent program

You can copy your concurrent programs and modify them to create new programs with definitions that meet your needs. You can modify how a concurrent program operates by changing the program's definition of:

Rather than overwrite a concurrent program's definition, you should customize a program by copying and renaming an existing program, then modifying the new program to suit your needs. The figure below illustrates the basic steps in copying and modifying a new concurrent program.

As the figure illustrates, you can copy parameters, and then modify the behavior of the parameters. Or you can copy the list of incompatible programs, and then modify the list. Finally , you can change the associated printer and/or print style.

the picture is described in the document text

Related Topics

Overview of Concurrent Programs and Requests

Copying and Modifying Program Definitions

Example of modifying a program's parameters

Concurrent Programs

Alter Program Priority

You may wish to control the priority of some requests on a program level rather than at the user level.

Setting the priority for a program allows any request to run that concurrent program to use your selected priority rather than the priority of the user submitting the request.

For example, a user can submit a variety of requests at the standard priority determined by the value of the user profile Concurrent:Priority. However, when the user submits a request for a particular concurrent program, you want that request to have a higher priority.

You assign that program a priority of 10. When the user requests that program to run, it receives the higher priority defined on the Concurrent Program window rather than the user's standard priority and is processed ahead of other requests. When the users requests other concurrent programs that do not have a specified priority, those requests use the user's Concurrent:Priority profile value.

Related Topics

Copying and Modifying Program Definitions

Concurrent Programs

Modifying an Incompatible Programs List

A concurrent program's definition may include a list of incompatible programs. When a program is listed as incompatible with another program, the two programs cannot run simultaneously in the same conflict domain. See: Defining Program Incompatibility Rules.

You can view which programs are incompatible with a concurrent program from the Incompatible Programs block on the Concurrent Programs window. The programs listed cannot run simultaneously within the same conflict domain as the concurrent program whose definition you are viewing.

To modify the list of incompatible programs you can either:

Add new programs to the list.

The Scope field refers to whether you want the program by itself to be incompatible, or whether you want the program and all child requests, that is, concurrent programs started by the program as part of a request set, to be incompatible.

Related Topics

Copying and Modifying Program Definitions

Concurrent Programs

Administer Concurrent Managers

Concurrent Program Parameters

Parameters, also referred to as arguments, are assigned to standard submission concurrent programs. To define a program as standard submission, set the value of the Standard Submission field in the Concurrent Programs form to Yes.

Important: All the mechanisms for parameter defaulting (including references to values of other parameters, user profiles, etc.) are evaluated only at submission time.

There are two aspects to a parameter associated with a concurrent program: its value set and its behavior.

Variable Description
Parameter value set The valid values the parameter can accept. The set of valid values is referred to as a value set.
Parameter behavior How the parameter behaves within an application. For example, whether:

  • an entry value for the parameter is required in order for the program to work

  • the parameter is displayed to the end user

  • a default value is automatically provided for the parameter

If you wish to define or modify a value set, you must first carefully plan your value set's purpose and implementation.

Using the Concurrent Programs form, you can see a concurrent program's parameters by choosing Parameters. Each parameter has a value set that defines what values are permissible for the parameter. To see the name of a parameter's value set, look at the Value Set field in the Argument Details block.

Related Topics

Copying and Modifying Program Definitions

Control the Behavior of Request Parameters

Example of modifying a program's parameters

Concurrent Programs

Control the Behavior of Request Parameters

The behavior of parameters in programs running individually may differ from when those programs are run as part of a request set.

You define how a program's parameters behave when you define the program using the Concurrent Programs form.

Using the Request Set form, you can also define how a program's parameters behave when the program is run as part of a request. In addition, you can define parameters in different programs in a request set to all share the same value by labeling them as Shared Parameters. See: Sharing Parameters in a Request Set.

Warning: Modifying a concurrent program's definition by adding new or deleting existing parameters, or changing a parameter's value set can prevent the program from running. See: Warnings for Modifying Program Definitions.

Not Displaying Parameters

Using the Concurrent Programs form or the Request Set form, you can set a parameter so it does not display to an end user. Because parameters that do not display cannot be modified, setting a parameter to not display:

If you define a parameter to not display, then the parameter does not appear when the program is run using the Submit Requests form, nor does it appear in the Request Set form.

If you define a parameter to not display, using the Request Set form, then the parameter does not appear on the Submit Requests form when the program is run as part of a request set.

Viewing displayed parameters after a request is submitted

After a request is submitted to run a concurrent program, the program's parameters may be displayed in the Details block of the Concurrent Requests form.

When a parameter is set to not display, it does not appear in the Details block of the Concurrent Requests form.

These displayed parameter values exactly match the values that the concurrent manager passes to the concurrent program, and may or may not correspond to the displayed value that the user chose.

For example, in the Submit Requests form, the user may choose "Oracle General Ledger" as a parameter, but the corresponding application ID displays in the Concurrent Requests form.

Tip: If your users encounter errors when running a program, you can look at the exact values that the concurrent program uses to help you diagnose the problem.

Setting Default Values for Parameters

Parameter default values can be changed by users when they submit a program or request set to run.

You can set a default value for a parameter using the:

Entering erroneous default values

If the Default Type or Default Value for a parameter is incorrect, when the program is being set to run using the Submit Requests form, a window displays along with an error message.

If the parameter is not displayed, you receive an error message. You cannot update a field that is not displayed.

Warning: Be careful when entering the default type and default value, because these values are not validated with the value sets for your parameters. If you enter incorrect values, they do not appear as defaults when you run this request set using the Submit Requests form.

Preventing modification of parameter values in a Request Set

If a parameter is displayed in the Request Set form and there is no default value provided by the program's definition, you can define a default value or have the parameter inherit a shared value, and then prevent end users from modifying that value.

Set the Modify field in the Request Set form to No if you want to show the value for a parameter but not allow changing it when the request set is run using a Standard Submission form. You can set a value for the parameter using a default value or a shared parameter.

If the Display field is set to No, the Modify field automatically defaults to No, and you cannot update it.

Caution: Set defaults for required parameters before turning Modify to No. Otherwise the Submit Requests form returns an error when attempting to submit this report.

Changing responsibility to see changes take effect

Modifying parameter behavior, for example, changing whether a parameter is displayed to the end user, takes effect immediately after you commit your change. However, some changes do not appear to you unless you change responsibility or select your current responsibility again.

Behavior of Program Parameters

The following table describes how a parameter's details affect its behavior in the Concurrent Programs form and the Run Requests form.

Parameter Details Concurrent Programs form Run Requests form
Required Yes Parameter requires a value (entered by user or a default).
Display Yes Parameter is displayed.
Display No Parameter is not displayed, and cannot be modified.
Default Type & Value Yes - Default Type and Value entered. A default value displays, and can be changed by the user.
Default Type and Value No default entered. No default value is displayed.

The following table describes how a parameter's details affect its behavior in the Request Sets form and Run Requests form.

Parameter Details Concurrent Programs form Request Set form Run Requests form
Required Yes Parameter does not require a value. Parameter requires a value.
Display Yes Parameter is displayed. - Display set to Yes. Parameter is displayed.
Display Yes Parameter is displayed. - Display set to No. Parameter is not displayed.
Display No Parameter not displayed. Parameter not displayed.
Modify n/a Yes Value can be modified.
Modify n/a No Value cannot be modified.
Default Type & Value Yes - Default Type and Value entered. Default Type and Value cannot be modified. Default values can be changed by the user.
Default Type & Value No default entered. Yes - a Default Type and Value can be entered. Default values can be changed by the user.
Default Type & Value No default entered. No - Default Type and Value are not entered. No default value is displayed.

Warnings for Modifying Program Definitions

The following table lists warnings for modifying program definitions:

Action Form Used Warning
Changing the number of columns or rows in a report program. Concurrent Programs - Report Information region. Some report programs are written to produce a precise output. Changing the output definition could prevent the program from running, or produce poor results.
Setting print style to Dynamic. Concurrent Programs - Report Information region - Style field. Dynamic print style informs the program to generate its output based on output dimensions that may vary. Special coding within a program is required to support the Dynamic print style.
Changing the number of parameters in a program definition. Concurrent Programs - Parameters window. Programs are defined to expect x number of parameters. If you add a new parameter (x + 1), the program will ignore it. Deleting a parameter can cause a program not to run.
Changing Value Sets. Concurrent Programs - Argument Details region - Value Set field. Programs expect values of a certain type and length. Programs may not operate if value set is changed.
Changing tokens. Concurrent Programs - Argument Details region - Token field. Programs expect values of a certain type and length. Program may not operate if expected token is not received.
Defining a concurrent executable or program's execution method as Immediate. Concurrent Program Executables - Execution Method field. Concurrent Programs - Executable Information region - Method field. Concurrent programs whose execution method is Immediate must be registered with the program library FNDLIBR. Application developers can register programs with program libraries, System Administrators cannot.

Related Topics

Copying and Modifying Program Definitions

Concurrent Program Parameters

Example of modifying a program's parameters

Concurrent Program Details Report

Example of modifying a program's parameters

Consider the following example of when and how to modify a concurrent program's parameters.

If one user submits a large number of concurrent requests on a daily basis, for example, an Oracle Bill of Materials or Oracle Purchasing supervisor, you can create a streamlined purge program that only purges that user's concurrent processing records.

You can run this program as System Administrator and have it automatically resubmitted on a specific time interval.

You could also create a request set containing this one program and define the user as the owner of the request set. Then, if you do not assign the request set to any report security group, only the user (owner) can run the program. This way, the user can be responsible for purging their own records.

The System Administrator's Purge Concurrent Request and/or Manager Data program contains twelve parameters. You can copy, rename, and modify the program so it displays only three parameters, with only one parameter requiring user entry. See: Purge Concurrent Request and/or Manager Data, Oracle E-Business Suite System Administrator's Guide - Maintenance.

The table below summarizes the steps to follow in our example.

Form Used Task
Concurrent Programs (Concurrent Programs Define) Query the Application Object Library program named "Purge Concurrent Request and/or Manager Data" and press Copy. Select both Copy Arguments and Copy Incompatible Programs. Enter a new name for the program you are going to copy, for example, enter JSMITH PURGE.
Concurrent Programs To modify the JSMITH PURGE program's parameters, select the Parameters button.
Concurrent Programs, Parameter Window Modify the following seven parameters so they do not display (user JSMITH cannot see nor change the program's default values). - Oracle ID - Program Application - Program - Manager Application - Manager - Responsibility Application - Responsibility Modify the following three parameters so they do not display (user JSMITH cannot see nor change the default values you set). Set the parameters to the following (Type=Constant) defaults: - Entity = Request - Mode = Age - User Name = JSMITH Leave the following two parameters unchanged so they display. Mode Value will require JSMITH to enter a value, and Report is set to a default value of "Yes". - Mode Value - Report
Request Set (Reports Set) Create a request set with one program in it, the JSMITH PURGE program. Enter JSMITH in the Owner field. If this request set is not assigned to any report security group, only JSMITH will be able to run the JSMITH PURGE program.
Standard Request Submission program form. For example, the Run Reports form (Reports Run) When first submitting the JSMITH PURGE program to run, navigate to the Resubmission Options region and enter, for example, "5" and "Days" in the Interval field.

Related Topics

Copying and Modifying Program Definitions

Concurrent Program Parameters

Control the Behavior of Request Parameters

Concurrent Program Details Report

Conflict Domains

A conflict domain is a set of related data stored in one or more ORACLE schemas and linked by grants and synonyms. Do not confuse logical databases with your ORACLE database. The ORACLE database contains all your Oracle E-Business Suite data, with each application's data usually residing in one ORACLE schema. You can think of a logical database as a line drawn around a set of related data for which you wish to define concurrent program incompatibilities. In other words, logical databases determine which concurrent programs cannot run at the same time.

Logical Databases and Program Incompatibilities

When an ORACLE schema is identified as belonging to a logical database, concurrent program incompatibility rules are enforced when concurrent programs connect to the ORACLE schema.

By checking for incompatibilities between programs running concurrently, accessing the same data, Oracle E-Business Suite ensures that data retrieved by one program is not incorrect or adversely affected when retrieved by another program.

Example - Program Incompatibilities

An example of a concurrent program that is incompatible with other concurrent programs is Oracle General Ledger's Posting program, used to post journal entries.

If the Posting program's incompatibility with other Oracle E-Business Suite concurrent programs were not enforced, other financial reports running simultaneously with the Posting program could contain incorrect account balance information. Logical databases ensure that this does not happen.

Defining Logical Databases

The installation process automatically defines logical databases and assigns ORACLE schemas to them.

A Standard logical database can be assigned to every Oracle E-Business Suite product so that every concurrent program, if incompatible with any other program, does not run concurrently with that program, regardless of which ORACLE schema those two programs connect to. Assigning every ORACLE schema to the same (e.g., Standard) logical database is a fail-safe method of enforcing program incompatibility rules.

You must define new logical databases only if you build a custom application whose data do not interact with data found in existing logical databases.

As a general rule, you should define a logical database for each custom application, and assign that application's ORACLE schema(s) to the corresponding logical database.

However, if a custom application's data interacts with another application's data, you should assign the two applications' ORACLE schemas to the same logical database.

Registering your custom application's tables ensures that the table names appear as QuickPick values in the Define Alerts form.

Concurrent Program Details Report

This report documents concurrent program definitions, including executable file information, execution method, incompatible program listings, and program parameters. If a concurrent program generates a report, column and row information, as well as print output and print style, are also documented.

Use this report when considering concurrent program modifications, such as modifying program incompatibility rules.

Report Parameters

Caution: If you do not enter any parameters, the report returns values for all concurrent programs, and may be very lengthy.

Application Name

Choose the application name associated with the concurrent program whose program definition details you wish to report on.

Choose only an application name, without a program name, if you wish to run a program definition details report on all concurrent programs associated with an application.

Program

Choose the name of a concurrent program whose program definition details you wish to report on. You must enter a value for Application Name before entering a value for Program.

Report Headings

The report headings display the specified report parameters and provide you with general information about the contents of the report.

Concurrent Programs Report

Concurrent Programs Report

This report shows which concurrent programs are currently enabled nand which programs are disabled.

Use this report to record the execution method, argument method, run alone status, standard submission status, request type, and print style information associated with your concurrent programs.

Report Parameters

Application Name

Choose the application name associated with the concurrent programs whose program information you wish to report on.

If you do not enter an application name, the report will return values for all concurrent programs.

Report Headings

The report headings display the specified report parameters and provide you with general information about the contents of the report.

Related Topics

Overview of Concurrent Programs and Requests

Concurrent Program Details Report

Concurrent Programs

Request Groups Window

the picture is described in the document text

Use this window to define a request group. A request security group is the collection of requests, request sets, and concurrent programs that a user, operating under a given responsibility, can select from the Submit Requests window.

System Administrators:

Users:

Request Groups Block

Group

Use the request group's name to assign the request group to a responsibility on the Responsibilities window. An application name and request group name uniquely identify a request group.

Application

Select the name of the application you wish to associate with your request group. An application name and a request security group name uniquely identify a request security group. This application name does not prevent you from assigning requests and request sets from other applications to this request group.

Code

Assign a code to this request group. Some products use the request group code as a parameter that identifies the requests a customized standard submission form can select. See: Customizing the Submit Requests Window using Codes.

Requests Block

Specify the requests and request sets in the request group.

Type

Choose program or set to add one item, or choose application to include all requests in an application.

Related Topics

Overview of Concurrent Programs and Requests

Organizing Programs into Request Groups

Using Codes with Request Groups

Customizing the Submit Requests Window using Codes

Report Group Responsibilities Report

Concurrent Program Executable Window

the picture is described in the document text

Define a concurrent program executable for each executable source file you want to use with concurrent programs. The concurrent program executable links your source file logic with the concurrent requests you and your users submit to the concurrent manager.

Important: You cannot add new immediate programs to a concurrent manager program library. We recommend that you use spawned concurrent programs instead.

Concurrent Program Executable Block

The combination of application name plus program name uniquely identifies your concurrent program executable.

See: Concurrent Programs Window

Executable

Enter a name for your concurrent program executable. In the Concurrent Programs window, you assign this name to a concurrent program to associate your concurrent program with your executable logic.

Short Name

Enter a short name for your concurrent program executable.

Application

The concurrent managers use the application to determine in which directory structure to look for your execution file.

Execution Method

The execution method cannot be changed once the concurrent program executable has been assigned to one or more concurrent programs in the Concurrent Programs window.

The possible execution methods are:

Variable Description
Host The execution file is a host script.
Oracle Reports The execution file is an Oracle Reports file.
PL/SQL Stored Procedure The execution file is a PL/SQL stored procedure.
Java Stored Procedure The execution file is a Java stored procedure.
Java Concurrent Program The execution file is a program written in Java.
Multi Language Function The execution file is a function (MLS function) that supports running concurrent programs in multiple languages (as well as territories and numeric character settings).
SQL*Loader The execution file is a SQL script.
SQL*Plus The execution file is a SQL*Plus script.
Spawned The execution file is a C or Pro*C program.
Immediate The execution file is a program written to run as a subroutine of the concurrent manager. We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.
Request Set Stage Function PL/SQL Stored Function that can be uesd to calculate the completion statuses of request set stages.

Execution File Name

Enter the operating system name of your execution file. Some operating systems are case sensitive, so the name entered here should match the file name exactly.

Do not include spaces or periods (.) in the execution file name, unless the execution method is PL/SQL stored procedure or Request Set Stage Function.

The maximum size of an execution file name is 60 characters.

Subroutine Name

Enter the name of your C or Pro*C program subroutine here. Do not use spaces or periods (.) in this field.

Only immediate programs or spawned programs using the Unified C API use the subroutine field.

We recommend against defining new immediate concurrent programs, and suggest you use either a PL/SQL Stored Procedure or a Spawned C Program instead.

Stage Function Parameters

The Stage Function Parameters button opens a window that allows you to enter parameters for the Request Set Stage Function. This button is only enabled when you select Request Set Stage Function as your Execution Method.

Stage Function Parameters Window

the picture is described in the document text

List the Parameters that your custom Stage Function uses.

Parameter

Enter a name for the Parameter. This name will be displayed in the Stage Functions Parameter window of the Request Set form.

Short Name

Enter a short name that will be used by the function to reference the parameter.

Related Topics

Concurrent Programs

Concurrent Programs Window

the picture is described in the document text

Use this window to define and modify your concurrent programs.

Prerequisites

Build the execution file for your concurrent program.

Use the Concurrent Program Executables window to define a concurrent program executable for your operating system program.

Concurrent Programs Block

The combination of application name plus program name uniquely identifies your concurrent program.

Program

You see this longer, more descriptive name when you view your requests in the Requests window. If this concurrent program runs through Standard Request Submission, you see this name in the Submit Requests window when you run this program.

Short Name

Enter a brief name that Oracle E-Business Suite can use to associate your concurrent program with a concurrent program executable.

Application

The program's application determines what ORACLE username your program runs in and where to place the log and output files.

Enabled

Indicate whether users should be able to submit requests to run this program and the concurrent managers should be able to run your program.

Disabled programs do not show up in users' lists, and do not appear in any concurrent manager queues. You cannot delete a concurrent program because its information helps to provide an audit trail.

(Executable) Executable: Name

Select the concurrent program executable that can run your program. You define the executable using the Concurrent Program Executables window. You can define multiple concurrent programs using the same concurrent program executable. See: Concurrent Program Executables.

(Executable) Executable: Options

Some execution methods, such as Oracle Reports, support additional execution options or parameters. You can enter such options in this field. The syntax varies depending on the execution method.

If you define a concurrent program with the bitmapped version of Oracle Reports, you can control the orientation of the bitmapped report by passing the ORIENTATION parameter or token. For example, to generate a report with landscape orientation, specify the following option in the Options field:

 ORIENTATION=LANDSCAPE

Do not put spaces before or after the execution options values. The parameters should be separated by only a single space. You can also specify an orientation of PORTRAIT.

You can control the dimensions of the generated output with the PAGESIZE parameter. A specified <width>x<height> in the Options field overrides the values specified in the report definition. For example:

 ORIENTATION=LANDSCAPE PAGESIZE=8x11.5

The units for your width and height are determined by your Oracle Reports definition. You set the units in your Oracle Reports menu under Report => Global Properties => Unit of Measurement.

If the page size you specify with the PAGESIZE parameter is smaller than what the report was designed for, your report fails with a "REP-1212" error.

(Executable) Executable: Method

The execution method your concurrent program uses appears here.

Valid values are:

Variable Description
Spawned Your concurrent program is a stand-alone program in C or Pro*C.
Host Your concurrent program is written in a script for your operating system.
Immediate Your concurrent program is a subroutine written in C or Pro*C. Immediate programs are linked in with your concurrent manage and must be included in the manager's program library.
Oracle Reports Your concurrent program is an Oracle Reports script.
PL/SQL Stored Procedure Your concurrent program is a stored procedure written in PL/SQL.
Java Stored Procedure Your concurrent program is a Java stored procedure.
Java Concurrent Program Your concurrent program is a program written in Java.
Multi Language Function A multi-language support function (MLS function) is a function that supports running concurrent programs in multiple languages (as well as territories and numeric character settings). You should not choose a multi-language function in the Executable: Name field. If you have an MLS function for your program (in addition to an appropriate concurrent program executable), you specify it in the MLS Function field.
SQL*Loader Your concurrent program is a SQL*Loader program.
SQL*Plus Your concurrent program is a SQL*Plus or PL/SQL script.
Request Set Stage Function PL/SQL Stored Function that can be used to calculate the completion statuses of request set stages.

You can switch between Spawned and Immediate, overriding the execution method defined in the Concurrent Program Executable window, only if either method appears when the executable is selected and both an execution file name and subroutine name have already been specified in the Concurrent Program Executable window. See: Concurrent Program Executables.

(Executable) Priority

You can assign this program its own priority. The concurrent managers process requests for this program at the priority you assign here.

If you do not assign a priority, the user's profile option Concurrent:Priority sets the request's priority at submission time.

(Request) Type

If you want to associate your program with a predefined request type, enter the name of the request type here. The request type can limit which concurrent managers can run your concurrent program.

(Request) Incrementor

For use by Oracle E-Business Suite internal developers only. The incrementor function is shown here.

(Request) MLS Function

The MLS function, if any, used by the program.

The Multilingual Concurrent Request feature allows a user to submit a request once to be run multiple times, each time in a different language. If this program utilizes this feature, the MLS function can be used to determine which installed languages are needed for the request.

Beginning with Release 12.1, MLS functions can support multiple territories and numeric character sets as well as multiple languages.

See:

Oracle E-Business Suite Developer's Guide

Note: If your program has an MLS function associated with it and the "Use in SRS" box (below) is not checked, then the MLS function will be ignored.

(Request) Use in SRS

Check this box to indicate that users can submit a request to run this program from a Standard Request Submission window.

If you check this box, you must register your program parameters, if any, in the Parameters window accessed from the button at the bottom of this window.

(Request) Allow Disabled Values

If you check the Use in SRS box, you can also check this box to allow a user to enter disabled or outdated values as parameter values.

Many value sets use special table columns that indicate whether a particular value is enabled (using ENABLED_FLAG, START_DATE_ACTIVE, and END_DATE_ACTIVE columns). These value sets normally allow you to query disabled or outdated values but not enter them in new data. For Standard Request Submission, this means that a user would not normally be allowed to enter disabled values as report parameter values when submitting a report, even if the report is a query-only type report.

(Request) Run Alone

Indicate whether your program should run alone relative to all other programs in the same logical database. If the execution of your program interferes with the execution of all other programs in the same logical database (in other words, if your program is incompatible with all programs in its logical database, including itself), it should run alone.

You can enter any specific incompatible programs in the Incompatible Programs windows.

(Request) Enable Trace

Turns on SQL tracing when program runs.

(Request) Restart on System Failure

Use this option to indicate that this concurrent program should automatically be restarted when the concurrent manager is restored after a system failure.

(Request) NLS Compliant

This box is checked if the program allows for a user to submit a request of this program that will reflect a language and territory that are different from the language and territory that the users are operating in.

For example, users can enter orders in English in the United Kingdom, using the date and number formats appropriate in the United Kingdom, then generate invoices in German using the date and number formats appropriate to their German customers.

If this box is left blank then a user can associate any installed language with the request, but the territory will default to the territory of the concurrent manager environment.

Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature. See: the Oracle E-Business Suite Developer's Guide.

Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature.

(Output) Format

Select the output format from the following:

(Output) Save

Indicate whether to automatically save the output from this program to an operating system file when it is run. This value becomes the default for all requests submitted for this program. The output of programs with Save set to No is deleted after printing.

If this is a Standard Request Submission program, users can override this value from the Submit Requests window.

(Output) Print

If you enter No, your concurrent program's output is never sent to the printer.

(Output) Columns / Rows

Enter the minimum column and row length for this program's report output. Oracle E-Business Suite uses this information to determine which print styles can accommodate your report.

(Output) Style

The print style you select depends on your system and printer setup. Print styles include:

Your list is limited to those styles that meet your program's columns and row length requirements.

(Output) Style Required

If your program requires a specific print style (for example, a checkwriting report), use this check box to enforce that print style.

(Output) Printer

If you want to restrict your program's output to a single printer, enter the name of the printer to which you want to send your output. If your program has minimum or maximum columns or rows defined, your list of values is limited to those printers that can support your program's requirements.

Users cannot override your choice of printer from the Submit Requests or Requests windows.

Business Events Region

Concurrent programs can be integrated with the Business Event System in Oracle Workflow. Business events can be raised at key points of the life cycle of a request to run a concurrent program. Users can subscribe to the business events and create their own business processes interacting with the concurrent programs.

Here you specify the points at which business events are enabled. The possible points are:

Possible parameters for each event are:

REQUEST_ID 
REQUESTED_BY 
PROGRAM_APPLICATION_ID 
CONCURRENT_PROGRAM_ID 
STATUS 
COMPLETION_TEXT 
TIME_STAMP

Concurrent Programs Buttons

Variable Description
Copy to... Choose this button to create another concurrent program using the same executable, request and report information. You can elect to copy the incompatibility and parameter details as well.
Session Control Choose this window to specify options for the database session of the concurrent program when it is executed.
Incompatibilities Choose this button to open the Incompatible Programs window.
Parameters Choose this button to open the Concurrent Program Parameters window.

Copy to Window

Create another concurrent program using the same executable, request and report information as the current program. You can optionally copy the incompatibility and parameter details information as well.

Related Topics

See: Incompatible Programs Window

Concurrent Program Parameters Window

Concurrent Program Executables

Session Control Window

Use this window to specify options for the database session of the concurrent program when it is executed.

Consumer Group

Optionally specify the resource consumer group for the concurrent program.

See: Resource Consumer Groups in Oracle E-Business Suite.

Rollback Segment

Optionally specify a rollback segment to be used with the concurrent program. This rollback segment will be used instead of the default and will be used up until the first commit.

Important: If you specify a rollback segment here, your concurrent program must use the APIs FND_CONCURRENT.AF_COMMIT and FND_CONCURRENT.AF_ROLLBACK to use the specified rollback segment. See: the Oracle E-Business Suite Developer's Guide.

Optimizer Mode

Optionally specify an optimizer mode. You can choose ALL_ROWS, FIRST_ROWS, Rules, or Choose. You would specify an optimizer mode only for a custom program that may not perform well with the default cost-based optimizer (CBO) and needs tuning. You can use a different optimizer mode until your program is tuned for CBO.

Target Node

If you are on a PCP/RAC environment, optionally specify the target node on which requests for this program will run. When requests for this program are submitted, they run on this node if possible.

If no specification is made for the concurrent program, a request will be picked up by any manager able to run it.

If the target node is down, any available manager will pick up the request for processing and log a message to FND_LOG_MESSAGES.

Target Instance

Optionally specify a Real Application Cluster (RAC) instance on which the program will run. When requests for this program are submitted, they run on this instance if possible.

Incompatible Programs Window

the picture is described in the document text

Identify programs that should not run simultaneously with your concurrent program because they might interfere with its execution. You can specify your program as being incompatible with itself.

Application

Although the default for this field is the application of your concurrent program, you can enter any valid application name.

Name

The program name and application you specify must uniquely identify a concurrent program.

Your list displays the user-friendly name of the program, the short name, and the description of the program.

Scope

Enter Set or Program Only to specify whether your concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).

Type

Enter Domain or Global. If you choose Domain, the incompatibility is resolved at a domain-specific level. If you choose Global, then this concurrent program will be considered globally incompatible with your concurrent program, regardless of which domain it is running in.

Related Topics

Concurrent Programs Window

Concurrent Program Parameters Window

Defining Program Incompatibility Rules

Modifying an Incompatible Programs List

Concurrent Program Parameters Window

the picture is described in the document text

Enter and update the program parameters that you wish to pass to the program executable. Program parameters defined here should match the variables in your execution file.

Conflicts Domain Parameter

Enter the parameter which will hold the value of the conflict domain of the program. For information on conflict domain parameters, see Concurrent Conflict Domains.

Enter the parameter which will hold the value of the conflict domain of the program.

Security Group

This field is for HRMS security only. See: Customizing, Reporting, and System Administration in Oracle HRMS.

Sequence

Choose the sequence numbers that specify the order in which your program receives parameter values from the concurrent manager.

Enabled

Disabled parameters do not display at request submission time and are not passed to your execution file.

Argument Detail

You specify information about your parameter almost exactly as you define a flexfield segment.

(Validation Information) Value Set

Enter the name of the value set you want your parameter to use for validation. You can only select from independent, table, and non-validated value sets.

The maximum size of your value set is 240 characters.

Important: If you are using a value set of dates, this value set should have a format type of either Standard Date or Standard DateTime if you are using the Multilingual Request feature.

(Validation Information) Default Type

If you want to set a default value for this parameter, identify the type of value you need.

Valid types include:

Variable Description
Constant The default value can be any literal value.
Profile The default value is the current value in the user profile option defined in the Default Value field. Use the profile option name, not the end-user name. You do not need to include $PROFILE$.
SQL Statement The default value is determined by the SQL statement you defined in the Default Value field.
Segment The default value is the value entered in a prior segment of the same parameter window.

(Validation Information) Default Value

You can enter a default value for the parameter. This default value for your parameter automatically appears when you enter your parameter window. You determine whether the default value is a constant or a context-dependent value by choosing the default type.

Your default value should be a valid value for your value set. Otherwise you see an error message when you enter your parameter window on the Run Request window and your default value does not appear.

Valid values for each default type include:

Variable Description
Constant Enter any literal value for the default value.
Profile The default value is the current value of the user profile option you specify here. Enter the profile option name, not the end-user name.
Segment The default value is the value entered in a prior segment of the same flexfield window. Enter the name of the segment whose value you want to copy.
SQL Statement The default value is determined by the SQL statement you enter here. Your SQL statement must return exactly one row and one column in all cases.

(Validation Information) Required

If the program executable file requires an argument, you should require it for your concurrent program.

(Validation Information) Enable Security

If the value set for this parameter does not allow security rules, then this field is display only. Otherwise you can elect to apply any security rules defined for this value set to affect your parameter list.

(Validation Information) Range

Choose either Low or High if you want to validate your parameter value against the value of another parameter in this structure. Parameters with a range of Low must appear before parameters with a range of High (the low parameter must have a lower number than the high parameter). For example, if you plan two parameters named "Start Date" and "End Date," you may want to force users to enter an end date later than the start date. You could assign "Start Date" a range of Low and "End Date" a range of High. In this example, the parameter you name "Start Date" must appear before the parameter you name "End Date."

If you choose Low for one parameter, you must also choose High for another parameter in that structure (and vice versa). Otherwise you cannot commit your changes.

(Window Information) Display

Indicate whether to display this parameter in the Parameters window when a user submits a request to run the program from the Submit Requests window.

You should provide a default type and value for any non-displayed parameter.

(Window Information) Display Size

Enter the field length in characters for this parameter. The user sees and fills in the field in the Parameters window of the Submit Requests window.

You should ensure that the total of the value set maximum sizes (not the display sizes) for all of your parameters, plus the number of separators you need (number of parameters minus one), does not add up to more than 240. If your program values' concatenated length exceeds 240, you may experience truncation of your data in some forms.

(Window Information) Description Size

Enter the display length in characters for the parameter value description. Your window may show fewer characters of your description than you specify here if there is not enough room (determined by the sum of your longest prompt plus your display size for this parameter plus seven). However, your window does not display more characters of the description than you specify here.

(Window Information) Prompt

A user sees the prompt instead of the parameter name in the Parameters window of the Submit Requests window.

(Window Information) Concatenated Description Size

Enter the display length in characters for the parameter value description. The user sees the parameter value in the Parameter Description field of the Submit Requests and View Requests forms. The Parameter Description field concatenates all the parameter values for the concurrent program.

Tip: We recommend that you set the Concatenated Description Size for each of your parameters so that the total Concatenated Description Size for your program is 80 or less, since most video screens are 80 characters wide.

(Window Information) Token

For a parameter in an Oracle Reports program, the keyword or parameter appears here. The value is case insensitive. For other types of programs, you can skip this field.

Related Topics

Concurrent Programs

Incompatible Programs Window

Data Groups Window

the picture is described in the document text

Note: Data groups are no longer supported. This section is provided for reference only.

Use this window to define data groups. A data group is a list of Oracle E-Business Suite and the ORACLE usernames assigned to each application.

An ORACLE username allows access to an application's tables in an ORACLE database. All data groups automatically include an entry for Application Object Library.

Each responsibility within Oracle E-Business Suite is assigned a data group.

During the installation or upgrading of Oracle E-Business Suite, a standard data group is defined, pairing each installed application with an ORACLE username (note: a standard data group is defined for each set of books). You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may:

Data Groups Block

Create a new data group, or modify an existing data group.

You cannot change or delete the predefined values for Application or ORACLE username in a Standard data group. However, you may modify the Tool ORACLE username and description, or add new Application-ORACLE username pairs to a Standard group.

Data Group

A data group is uniquely identified by its name. You cannot create a data group with a name already in use.

Once saved, data group names cannot be edited.

Application-ORACLE ID Pairs Block

Pair applications with ORACLE usernames.

When you copy a data group, each application, its assigned ORACLE username, and, if present, its Tool ORACLE username and description, appear in this zone automatically. All data groups automatically include an entry for Application Object Library.

Application

Within each data group, an application can be listed only one time.

Oracle ID

Select the ORACLE ID you want to assign to an application. An application uses an ORACLE ID to access tables in the database. Each ORACLE ID allows access to a predefined set of tables in the database.

Copy Applications From...

Use this button to copy an existing data group, then add or delete application-ORACLE username pairs to create a new data group.

Related Topics

Overview of Concurrent Programs and Requests

Concurrent Conflicts Domains Window

the picture is described in the document text

Concurrent conflicts domains ensure that incompatible concurrent programs are not allowed to run simultaneously using related information.

For example, a conflict domain could be a range of numbers. Two concurrent programs could be incompatible if they used the same range of numbers, but compatible if they used different ranges of numbers.

Concurrent managers use concurrent conflicts domains to determine which concurrent programs cannot run at the same time. For example:

To define a conflict domain:

  1. Enter a unique Domain name. The name you enter here may be used as a value for a parameter in the Submit Requests window.

  2. Enter a unique Short Name for your domain. Limit the Short Name to 8 characters.

  3. Optionally, you can provide a description for your domain.

Related Topics

Overview of Applications DBA Duties

ORACLE Usernames (Overview)

ORACLE Users

Applications

Concurrent Programs HTML UI

Search for Concurrent Programs

Use this page to search for defined concurrent programs.

From this page you can create a new concurrent program or update an existing one.

Create Concurrent Program

The following are prerequisites to defining a concurrent program:

The combination of application name plus program name uniquely identifies your concurrent program.

Update Annotation

Optionally enter an annotation for the Integration Repository for the concurrent program.

Enabled

Indicate whether users should be able to submit requests to run this program and the concurrent managers should be able to run your program.

Disabled programs do not show up in users' lists, and do not appear in any concurrent manager queues. You cannot delete a concurrent program because its information helps to provide an audit trail.

Program

You see this longer, more descriptive name when you view your requests in the Requests window. If this concurrent program runs through Standard Request Submission, you see this name in the Submit Requests window when you run this program.

Application

The program's application determines what ORACLE username your program runs in and where to place the log and output files.

Short Name

Enter a brief name that Oracle E-Business Suite can use to associate your concurrent program with a concurrent program executable.

Program Type

Available options are:

Executable

Enter the following:

Name

Select the concurrent program executable that can run your program. You define the executable using the Concurrent Program Executables window. You can define multiple concurrent programs using the same concurrent program executable.

Parameters

Parameters for the concurrent program are listed here. To add a parameter, click on the Create button.

Incompatibilities

Identify programs that should not run simultaneously with your concurrent program because they might interfere with its execution. You can specify your program as being incompatible with itself.

Conflict Domain Parameter

Enter the parameter which will hold the value of the conflict domain of the program.

For information on conflict domain parameters, see Concurrent Conflict Domains.

Run Alone

Indicate whether your program should run alone relative to all other programs in the same logical database. If the execution of your program interferes with the execution of all other programs in the same logical database (in other words, if your program is incompatible with all programs in its logical database, including itself), it should run alone.

You can enter any specific incompatible programs in the Incompatible Programs windows.

Application

Although the default for this field is the application of your concurrent program, you can enter any valid application name.

Name

The program name and application you specify must uniquely identify a concurrent program.

Your list displays the user-friendly name of the program, the short name, and the description of the program.

Scope

Enter Set or Program Only to specify whether your concurrent program is incompatible with this program and all its child requests (Set) or only with this program (Program Only).

Type

Choose the type of incompatibility, either Domain or Global.

For information on incompatibility types, see Incompatible and Run Alone Programs.

Request

Enter the following:

Request Settings

Enter the following:

Type

If you want to associate your program with a predefined request type, enter the name of the request type here. The request type can limit which concurrent managers can run your concurrent program.

Incrementor

For use by Oracle E-Business Suite internal developers only. The incrementor function is shown here.

MLS Function

The MLS (Multi-Lingual Support) function, if any, used by the program.

The Multilingual Concurrent Request feature allows a user to submit a request once to be run multiple times, each time in a different language. If this program utilizes this feature, the MLS function determines which installed languages are needed for the request.

Beginning with Release 12.1, multiple territories and numeric character settings are also supported.

See the Oracle E-Business Suite Developer's Guide for more information.

Activity Summarizer

For internal use only.

The Activity Summarizer is a PL/SQL subprogram summarizing about the purgable data in application tables for a concurrent program of type "Purge". It returns a list of table names and rows to be purged. Oracle developers register the PL/SQL procedure as summarizer procedure for the concurrent program.

Refresh Portlet

For internal use only.

Concurrent programs that produce data for a portlet can call a function to refresh the portlet's data. The value for Refresh Portlet indicates when the function should be called.

Allow Multiple Pending Requests

If this box is checked, multiple pending requests are allowed; otherwise, only one pending request is allowed.

Use in SRS

Check the SRS (Standard Request Submission) box to indicate that users can submit a request to run this program from a Standard Request Submission window.

If you check this box, you must register your program parameters, if any, in the Parameters window accessed from the button at the bottom of this window.

Allow Disabled Values

If you check the Use in SRS box, you can also check this box to allow a user to enter disabled or outdated values as parameter values.

Many value sets use special table columns that indicate whether a particular value is enabled (using ENABLED_FLAG, START_DATE_ACTIVE, and END_DATE_ACTIVE columns). These value sets normally allow you to query disabled or outdated values but not enter them in new data. For Standard Request Submission, this means that a user would not normally be allowed to enter disabled values as report parameter values when submitting a report, even if the report is a query-only type report.

Restart on System Failure

Use this option to indicate that this concurrent program should automatically be restarted when the concurrent manager is restored after a system failure.

NLS Compliant

The NLS (National Language Support) box is checked if the program allows for a user to submit a request of this program that will reflect a language and territory that are different from the language and territory that the users are operating in.

For example, users can enter orders in English in the United Kingdom, using the date and number formats appropriate in the United Kingdom, then generate invoices in German using the date and number formats appropriate to their German customers.

If this box is left blank then a user can associate any installed language with the request, but the territory will default to the territory of the concurrent manager environment.

Note that this option should be set only by the developer of the program. The program must be written as NLS Compliant to utilize this feature. See: Oracle E-Business Suite Developer's Guide.

Output Preferences

Enter the following:

Save

Indicate whether to automatically save the output from this program to an operating system file when it is run. This value becomes the default for all requests submitted for this program. The output of programs with Save set to No is deleted after printing.

If this is a Standard Request Submission program, users can override this value from the Submit Requests window.

Print

If you enter No, your concurrent program's output is never sent to the printer.

Format

Select the output format from the following:

The format that you select here is used by the concurrent manager to determine how to display your report output. You must ensure that the output format you choose matches the format generated by your report, unless the report is an Oracle Reports report in which case the format you select, determines the output generated.

Columns / Rows

Enter the minimum column and row length for this program's report output. Oracle E-Business Suite uses this information to determine which print styles can accommodate your report.

Style

The print style you select depends on your system and printer setup. Print styles include:

Your list is limited to those styles that meet your program's columns and row length requirements.

Style Required

If your program requires a specific print style (for example, a checkwriting report), use this check box to enforce that print style.

Onsite Setting

The following fields are typically specific to the installation.

General

Enter the following:

Priority

You can assign this program its own priority. The concurrent managers process requests for this program at the priority you assign here.

If you do not assign a priority, the user's profile option Concurrent:Priority sets the request's priority at submission time.

Printer

If you want to restrict your program's output to a single printer, enter the name of the printer to which you want to send your output. If your program has minimum or maximum columns or rows defined, your list of values is limited to those printers that can support your program's requirements.

Users cannot override your choice of printer from the Submit Requests or Requests windows.

Template

The default layout template for the program. Values for this field are available only if the concurrent program has been registered as a data definition with XML Publisher and templates have been loaded to the Template Manager. For more information on XML Publisher and the Template Manager, see the Oracle XML Publisher documentation..

At the time of request submission, the default template is presented to the user. The user can override this value when submitting the request.

Retain for

This field indicates how many days the system should retain data for a request of this concurrent program after the request completes. The system will retain this data for this period even if the "Purge Concurrent Request and/or Manager Data" program is run during this time.

Security Group

This field is for HRMS security only. See: Customizing, Reporting, and System Administration in Oracle HRMS.

Log Level for Failure

The log level is used in diagnostics. If a request to run this concurrent program fails, the failure may be recorded in a log file with the specified log level.

Enable Trace

Turns on SQL tracing when program runs.

Enable Time Statistics

Enables the collection of timed statistics, such as CPU and elapsed times, by the SQL trace facility, as well as the collection of various statistics in the dynamic performance tables.

Delete Log File

By default, a log file is created for each concurrent request. If such log files are not necessary for requests for this concurrent program, you can specify that the log file is automatically deleted for each request of this program.

Target Settings

If you are on a PCP/RAC environment, optionally specify the target node on which requests for this program will run. If no specification is made for the concurrent program, the request will be picked up by any manager able to run it.

If the target node is down, any available manager will pick up the request for processing and log a message to FND_LOG_MESSAGES.

Session Controls

Use this region to specify options for the database session of the concurrent program when it is executed.

Consumer Group

Optionally specify the resource consumer group for the concurrent program. See: Resource Consumer Groups in Oracle E-Business Suite.

Rollback Segment

Optionally specify a rollback segment to be used with the concurrent program. This rollback segment will be used instead of the default and will be used up until the first commit.

Important: If you specify a rollback segment here, your concurrent program must use the APIs FND_CONCURRENT.AF_COMMIT and FND_CONCURRENT.AF_ROLLBACK to use the specified rollback segment. See: Oracle E-Business Suite Developer's Guide.

Optimizer Mode

Optionally specify an optimizer mode. You can choose ALL_ROWS, FIRST_ROWS, Rules, or Choose. You would specify an optimizer mode only for a custom program that may not perform well with the default cost-based optimizer (CBO) and needs tuning. You can use a different optimizer mode until your program is tuned for CBO.

Statistics

This region provides statistics on earlier requests for a defined concurrent program.

Summary information is collected when a request is completed, and stored in the table fnd_conc_prog_onsite_info.

Concurrent Program - Add Parameter

Enter and update the program parameters that you wish to pass to the program executable. Program parameters defined here should match the variables in your execution file.

General

Enter the following:

Enabled

Disabled parameters do not display at request submission time and are not passed to your execution file.

Sequence

Choose the sequence numbers that specify the order in which your program receives parameter values from the concurrent manager.

Parameter

Enter the parameter name. The value is case insensitive.

Validation

Enter the following:

Value Set

Enter the name of the value set you want your parameter to use for validation. You can only select from independent, table, and non-validated value sets.

The maximum size of your value set is 240 characters.

Important: If you are using a value set of dates, this value set should have a format type of either Standard Date or Standard DateTime if you are using the Multilingual Request feature.

Default Type

If you want to set a default value for this parameter, identify the type of value you need.

Valid types include:

Variable Description
Constant The default value can be any literal value.
Profile The default value is the current value in the user profile option defined in the Default Value field. Use the profile option name, not the end-user name. You do not need to include $PROFILE$.
SQL Statement The default value is determined by the SQL statement you defined in the Default Value field.
Segment The default value is the value entered in a prior segment of the same parameter window.

Default Value

You can enter a default value for the parameter. This default value for your parameter automatically appears when you enter your parameter window. You determine whether the default value is a constant or a context-dependent value by choosing the default type.

Your default value should be a valid value for your value set. Otherwise you see an error message when you enter your parameter window on the Run Request window and your default value does not appear.

Valid values for each default type include:

Variable Description
Constant Enter any literal value for the default value.
Profile The default value is the current value of the user profile option you specify here. Enter the profile option name, not the end-user name.
Segment The default value is the value entered in a prior segment of the same flexfield window. Enter the name of the segment whose value you want to copy.
SQL Statement The default value is determined by the SQL statement you enter here. Your SQL statement must return exactly one row and one column in all cases.

Required

If the program executable file requires an argument, you should require it for your concurrent program.

Enable Security

If the value set for this parameter does not allow security rules, then this field is display only. Otherwise you can elect to apply any security rules defined for this value set to affect your parameter list.

Range

Choose either Low or High if you want to validate your parameter value against the value of another parameter in this structure. Parameters with a range of Low must appear before parameters with a range of High (the low parameter must have a lower number than the high parameter). For example, if you plan two parameters named "Start Date" and "End Date", you may want to force users to enter an end date later than the start date. You could assign "Start Date" a range of Low and "End Date" a range of High. In this example, the parameter you name "Start Date" must appear before the parameter you name "End Date".

If you choose Low for one parameter, you must also choose High for another parameter in that structure (and vice versa). Otherwise you cannot commit your changes.

If your value set is of the type Pair, this field is display only. The value defaults to Pair.

Display

Enter the following:

Display

Indicate whether to display this parameter in the Parameters window when a user submits a request to run the program from the Submit Requests window.

You should provide a default type and value for any non-displayed parameter.

Token

For a parameter in an Oracle Reports program, the keyword or parameter appears here. The value is case insensitive. For other types of programs, you can skip this field.

Description Size

Enter the display length in characters for the parameter value description. Your window may show fewer characters of your description than you specify here if there is not enough room (determined by the sum of your longest prompt plus your display size for this parameter plus seven). However, your window does not display more characters of the description than you specify here.

Display Size

Enter the field length in characters for this parameter. The user sees and fills in the field in the Parameters window of the Submit Requests window.

You should ensure that the total of the value set maximum sizes (not the display sizes) for all of your parameters, plus the number of separators you need (number of parameters minus one), does not add up to more than 240. If your program values' concatenated length exceeds 240, you may experience truncation of your data in some forms.

The default is the name of the parameter.

Prompt

A user sees the prompt instead of the parameter name in the Parameters window of the Submit Requests window.

Concatenated Description Size

Enter the display length in characters for the parameter value description. The user sees the parameter value in the Parameter Description field of the Submit Requests and View Requests forms. The Parameter Description field concatenates all the parameter values for the concurrent program.

Tip: We recommend that you set the Concatenated Description Size for each of your parameters so that the total Concatenated Description Size for your program is 80 or less, since most video screens are 80 characters wide.