Concurrent Processing

Before you decide which types of activities occur concurrently within General Ledger, you must understand which tables are accessed by background and reporting processes. The tables accessed by various processes can affect the processes that you run concurrently with online activity or with other background programs.

Concurrency is important in the usage of both physical and functional tables:

• Physical usage.

  Certain processes bar access to tables required of other processes, so those processes cannot be run concurrently. Physical usage is based on an analysis of the unit of work anticipated in the environment, along with the type of table access a background or reporting process performs. This depends on the SQL access type. Multiple processes can perform Select access against a table. Delete, Update, and Insert access can cause table or row locking (depending on the platform). In turn, this might cause a conflicting and concurrently running process to pause or take a time-out.

• Functional usage.

  Although a table may be physically available, it might cause problems if changes are made while a process is running. Consider the elimination set tables used by the Consolidation background process. Functionally, you do not want a user to modify the elimination set definitions online while another user runs the Consolidation process to generate elimination entries. This can result in unexpected or inaccurate results for the user running the background process. User and object security are two system tools that can provide segregation of functional access to tables online and in the background.

Most of the General Ledger batch processes are designed to enable efficient concurrent processing by using nonshared temporary tables to minimize contention on these tables. Each process has its own temporary table when multiple jobs run concurrently. For example, if two Equitization jobs (GLPQEQTZ) are running, the first job uses EQTZ_SUB_TMP001 and the second job uses EQTZ_SUB_TMP002.

For COBOL processes, the nonshared tables are maintained in table TEMP_TBL_ASGNM. General Ledger provides a set of four nonshared tables for each temporary table. The system administrator can add more nonshared temporary tables if necessary. If all temporary tables are in use—for example, one job is submitted while four other jobs run concurrently—the shared temporary table (CURR_WRK_TBL in the case of the Currency Translation process) is shared by the fifth job and by subsequent jobs submitted.

For Application Engine processes, the nonshared tables are maintained in the tools tables. The number of instances of nonshared temporary tables is specified in the Application Engine properties. For example, the number of temporary table instances for the Combo Edit process is set to 4.