Search Results apply_hold

Overview

The concurrent program IGSAZJ03, presented to users under the name Apply Advising Hold, belongs to the IGS – Student System product family within Oracle E-Business Suite. Its documented purpose is to apply advising holds to the students who make up a specified advising group. In academic institutions running the Oracle Student System, advising holds are used to restrict or flag a student’s record — for example, preventing registration or blocking certain transactions — until an academic advisor has completed a required review or intervention. This program automates that hold-placement step across an entire advising population rather than requiring staff to apply holds one student at a time.

The object is documented in ETRM for release 12.2.2 and carries the product designation “IGS – Student System (Obsolete).” The “Obsolete” marker indicates that this functionality reflects an earlier generation of the Student System and may not be supported in current deployments, but the metadata remains valid as a reference for installations that still use it. The program is recorded as Enabled: Yes, meaning it is available for submission where the module is installed.

Execution Details

The documented execution attributes for IGSAZJ03 are as follows:

• Execution Method: PL/SQL Stored Procedure
• Argument Method: Standard
• Executable: IGSAZJ03
• Executable User Name: IGSAZJ03
• Execution Filename: IGS_AZ_GEN_001.APPLY_HOLD
• Subroutine Name: (not specified)

Because the execution method is PL/SQL Stored Procedure, Oracle EBS invokes the packaged procedure named in the execution filename — specifically the APPLY_HOLD procedure inside the package IGS_AZ_GEN_001. This is distinct from a concurrent-manager “Host” or “Java” invocation and means the logic runs directly inside the database session managed by the concurrent manager. The use of the Standard argument method indicates that parameters, where defined, are passed as ordinary concurrent program arguments (typically a combination of text and number values) through the Standard Submission form rather than through a token-based or environment-specific mechanism.

How to Run

The program is submitted through the standard Oracle EBS Submit Requests (SRS) window, generally by a user with responsibility over advising or student records administration. Typical navigation follows the pattern Requests → Run, after which the user selects “Apply Advising Hold” from the list of available concurrent programs. The request may also be launched programmatically using the FND_REQUEST.SUBMIT_REQUEST API, which accepts the concurrent program’s application short name and program short name along with any defined arguments.

Because the ETRM metadata documents the argument method as Standard but does not enumerate individual parameters, the exact argument list is not captured here. In practice, a program of this type generally requires the user to identify the advising group whose students are to receive the hold, so the submission form would be expected to prompt for an advising group identifier and possibly an effective date or hold reason. Administrators should confirm the precise parameter set in the Concurrent Programs definition form (Application Developer → Concurrent → Program) before submitting, since parameters determine which students are affected. Because the program applies holds in bulk, it is advisable to test the submission against a limited advising group or in a non-production environment first.

Related Objects

The Apply Advising Hold program operates within the broader IGS advising data model. Objects commonly associated with this area include:

• Advising group definitions and membership tables within the IGS schema, which supply the population of students to whom holds are applied.
• Student hold and advising APIs, which the package IGS_AZ_GEN_001 uses to create or update hold records rather than writing directly to base tables.
• Executable and concurrent program definitions (IGSAZJ03) that bind the user-facing name to the underlying stored procedure.
• Request output and log files generated by the concurrent manager, which record how many students were processed and whether any errors occurred.
• Related IGS concurrent programs in the same family (for example, programs that release or remove advising holds), which are typically run in conjunction with this one to manage the complete hold lifecycle.

Because the underlying module is marked obsolete, administrators should verify whether these objects remain present and supported in their specific EBS 12.1.1 or 12.2.2 environment before relying on IGSAZJ03 for hold processing.