Search Results xla_debug_level

Overview

XLA_UTILITY_PKG is a shared infrastructure package owned by APPS within the Oracle E-Business Suite Subledger Accounting (XLA) product family. Its documented purpose is to provide a unified wrapper for debugging, benchmarking, and testing facilities used throughout the XLA processing stack. It does not perform accounting, journal creation, or transaction mapping; instead it supplies cross-cutting instrumentation services that other XLA packages call at runtime. Three functional areas are supported: trace and debug output, concurrent program output and logfile writing, and statistical benchmarking.

The package header carries the revision marker xlacmutl.pkh 120.5 and the copyright notice for 2000–2002, confirming that it has been part of the XLA architecture since the original release and has remained stable. ETRM classifies the API as OTHER, reflecting its role as a utility rather than a public business interface. Its influence is broad: the metadata records that it is referenced by 39 other packages, making it one of the most widely depended-upon objects in the XLA schema. The activate_stat entry point is one of several activation toggles that turn the package's instrumentation services on.

Key Procedures and Functions

The documented API surface contains 23 procedures and functions. The principal groups are:

• ACTIVATE / DEACTIVATE — general activation and deactivation entry points that prime the utility package for subsequent operations.
• SET_OPTION, GET_OPTION_VALUE, GET_SESSION_INFO — control and inspection of runtime options and session-level context.
• ACTIVATE_TRACE, DEACTIVATE_TRACE, SET_TRACE_ON, SET_TRACE_OFF, TRACE, PRINT_TRACE_INFO — control the diagnostic trace subsystem, including emitting individual trace messages and reporting current trace configuration. Trace behavior is governed by the profile options XLA_DEBUG_MODE, XLA_DEBUG_LEVEL, and XLA_DEBUG_TIMEOUT.
• PRINT, PRINT_OUTPUTFILE, PRINT_LOGFILE — route messages to standard output, the concurrent program output file, or the concurrent program logfile.
• ACTIVATE_STAT, DEACTIVATE_STAT, SET_STAT_ON, SET_STAT_OFF, PRINT_STAT_INFO, GET_STAT_INFO — the statistical benchmarking group. The source header documents the usage pattern of calling init_stat before a code block and stat_off afterwards; the shipped API names the equivalent toggles ACTIVATE_STAT and DEACTIVATE_STAT.

No parameter lists are reproduced here, as ETRM documents procedure names and purposes only. Callers should resolve exact signatures from the deployed package specification.

Tables Accessed

The documented references are to supplied infrastructure rather than to application data tables, which is consistent with the package's diagnostic role. The dependencies are DBMS_PIPE (used when trace output is piped to a waiting concurrent process), DBMS_SESSION and DBMS_UTILITY (session state and timing utilities underpinning the statistics and session-info calls), HTP (rendering trace output as an HTML page), UTL_FILE (writing trace output to a flat file), and V$PARAMETER (reading database initialization parameters such as the user dump and trace destinations used by the trace subsystem). All are reached through APPS synonyms. No XLA transaction, accounting, or setup tables are documented as being read or written.

Usage Notes

The package is invoked from concurrent programs, Oracle Forms, and SQL*Plus or custom PL/SQL. From a concurrent program or Form, instrumentation is normally enabled through the XLA profile options, and output is directed to the concurrent output or logfile. From SQL*Plus, the documented pattern is to call xla_utility_pkg.init_trace with a mode of OUTPUT or FILE plus a location, execute the target PL/SQL, then call trace_off. Within instrumented code the standard idiom is to call init_trace, emit TRACE calls with a trace level, and terminate with trace_off. The same pattern applies to statistics, using the activation, deactivation, and print-information procedures around the measured block. Because the package is a helper rather than a business API, it should be called only for diagnostics, benchmarking, or test harness purposes and should not be embedded in production accounting logic. Debug mode should remain disabled during normal period-close and posting runs, since trace output to a file or pipe adds measurable overhead.