Search Results kill_jobs
Overview
MSD_DEM_SOP is an Oracle Application Object Library (APPS) PL/SQL package that supports the Demand Planning and Supply Chain Intelligence (SCI) data collection and download functionality within Oracle E-Business Suite Advanced Supply Chain Planning. The package is declared with AUTHID DEFINER, meaning it executes with the privileges of its owning schema rather than the invoking user. Its header identifies a source file msddemsops.pls with a version signature from 2012, placing it within the Oracle EBS 12.1.1 and 12.2.2 code lines.
Functionally, the package orchestrates the movement of planning data from the planning server into the demand planning repository. It manages job submission and control, plan attribute configuration, plan member loading, item cost retrieval, and the collection and loading of SCI-specific data series. A set of global constants defined at the package level reveal its integration points: values from MSD_DEM_COMMON_UTILITIES, an ASCP series identifier for item cost, and lookup codes that classify planning entities as material, product, resource, or work order. The package also reads profile options such as MSD_DEM_DEBUG_MODE and MSD_DEM_SCHEMA at initialization.
Key Procedures and Functions
The documented procedures fall into several functional groups. Plan configuration and loading are handled by SET_PLAN_ATTRIBUTES, LOAD_PLAN_DATA, and LOAD_PLAN_MEMBERS. Two overload variants, LOAD_PLAN_DATA_WO_PDS and LOAD_PLAN_DATA_WO_ODS, govern plan loading without PDS or ODS involvement respectively. These procedures expose parameters for controlling job-based execution, batch splitting by organization, job check intervals, and job timeouts, indicating that long-running loads are dispatched asynchronously.
Download lifecycle management is provided by POST_DOWNLOAD_HOOK and WAIT_UNTIL_DOWNLOAD_COMPLETE, which coordinate the completion of data transfers before downstream processing proceeds. Cost data is retrieved through LOAD_ITEM_COST and LOAD_COST. Series-level loading is handled by LOAD_SERIES_DATA_BATCH.
SCI-specific collection and loading is performed by COLLECT_SCI_DATA and LAUNCH_SCI_DATA_LOADS. Work order supply resolution is accomplished through GET_WO_SUPPLY_ID_FROM_DEMAND and GET_WO_SUPPLY_ID_FROM_SUPPLY. Finally, KILL_JOBS is the procedure directly relevant to the "kill_jobs" search: it provides the mechanism by which background jobs submitted by the package are terminated, drawing on the DBMS_JOB and USER_JOBS infrastructure referenced in the package.
Tables Accessed
The package operates against planning and job-control data dictionary objects accessed through APPS synonyms. MSC_PLANS, MSC_PLAN_BUCKETS, MSC_PLAN_ORGANIZATIONS, and MSC_PLAN_SCHEDULES supply the plan definitions, time buckets, organization assignments, and scheduling information required for plan loading and member selection. MSC_APPS_INSTANCES supports coordination between the planning application instances involved in distributed processing. MSD_DEM_SERIES stores the demand series data that the SCI collection and batch load procedures populate. Job management relies on DBMS_JOB, USER_JOBS, and DBA_OBJECTS, which together allow the package to submit, monitor, and terminate asynchronous jobs — the basis for the KILL_JOBS procedure. DBMS_LOCK provides serialization control for concurrent execution, and DBMS_RANDOM likely supports generation of unique job or batch identifiers.
Usage Notes
MSD_DEM_SOP is an internal planning package rather than a public API; the ETRM classification records it as OTHER. It is typically invoked by concurrent programs, by other planning packages (it is referenced by two other packages), or by scheduled job infrastructure during demand planning data collection runs. Because several procedures accept job-control parameters such as p_use_jobs, p_job_check_interval, and p_jobs_timeout, administrators should be aware that failed or hung loads may leave orphaned DBMS_JOB entries. The KILL_JOBS procedure addresses exactly this operational scenario, allowing pending or runaway jobs spawned during a plan load to be terminated cleanly. Custom code should not call these procedures directly unless the calling context fully reproduces the expected profile option settings and plan state.