Search Results conc_print_output




Overview
Explore in AI Chat

Overview

FND_CONC_GLOBAL is a public PL/SQL package in the APPS schema that provides the runtime context for a concurrent program that is executing at any given moment. Its central purpose is to expose the "request globals" of the currently running concurrent request — values such as print copies, hold status, priority, save-output flag, single-thread flag, printer, and print-together/print-output options — so that a running program can read those settings and apply them, particularly when submitting sub-requests from within a PL/SQL concurrent program. The package header comment states explicitly that it "is used for submitting sub-requests from PL/SQL concurrent programs." In Oracle EBS 12.1.1 and 12.2.2 it is classified as an OTHER API under product FND, associated with the business entity FND_CP_REQUEST, and is marked active with compatibility S (supported). It is a heavily reused utility: ETRM records that it is referenced by 111 other packages, reflecting its role as the standard mechanism for propagating request-level options to child or sub-requests.

Key Procedures and Functions

The package exposes fifteen documented functions and procedures. The bulk are simple getter functions that return the value of a request global:

  • CONC_COPIES — returns the number of copies to print for the concurrent process.
  • CONC_HOLD — returns whether the concurrent process is to be temporarily held.
  • CONC_PRIORITY — returns the priority for running the concurrent process.
  • CONC_SAVE_OUTPUT — returns the save-output flag so the process output is retained.
  • CONC_SINGLE_THREAD — returns whether the process should run single-threaded.
  • PRINTER — returns the printer associated with the request.
  • CONC_PRIORITY_REQUEST — returns the priority value for the current request; this is the entry point surfaced by the search term "conc_priority_request."
  • CONC_PRINT_TOGETHER — returns the print-together option.
  • CONC_PRINT_OUTPUT — returns the print-output option.
  • REQUEST_DATA — returns state information saved by the parent request, used for passing context into sub-requests.
  • OVERRIDE_OPS_INST_NUM and OPS_INST_NUM — manage the operations instance number override and the current instance number.
  • INITIALIZE — initializes the package state for the running request.
  • GET_REQ_GLOBALS and SET_REQ_GLOBALS — retrieve and assign the full set of request globals.

The getter functions are declared with pragma restrict_references (WNDS, WNPS), making them safe to call from SQL and from within PL/SQL without side effects on package or database state.

Tables Accessed

ETRM documents only one underlying object referenced through APPS synonyms: V$INSTANCE. This dynamic performance view is read to determine the current database instance identity, which underpins the instance-number functions (OPS_INST_NUM and OVERRIDE_OPS_INST_NUM) and supports correct behavior in multi-instance (RAC) deployments. The remaining request globals are held in package state rather than being read from base tables; there is no documented direct access to FND_CONCURRENT_REQUESTS or related tables by this package. Where a program needs persistent request attributes, it obtains them through the getters here or through the sibling APIs that populate the globals.

Usage Notes

FND_CONC_GLOBAL is invoked at run time by PL/SQL concurrent programs, most often when the program submits sub-requests and needs to inherit the parent request's printing, priority, hold, and output settings. A typical pattern is to read the relevant globals in the parent, then pass them through to child request submission APIs so that sub-requests behave consistently with the parent. The package is not a user-facing form API; it is called from custom concurrent program code and from the many standard packages that reference it. Because the getters are WNDS/WNPS-restricted, they may safely be called in queries. The INITIALIZE, GET_REQ_GLOBALS, and SET_REQ_GLOBALS routines manage the lifecycle of the global state, while CONC_PRIORITY_REQUEST supplies the request priority specifically. In 12.1.1 and 12.2.2 the calling conventions and getter semantics are unchanged, and the package is supported (compatibility S) for both releases.