How PSUB Handles a Request

When a user issues a PSUB request to run a job or report, the ocpsub database account acts as a proxy for the user (see Securing PSUB). The system sends a message via Oracle Advanced Queue (AQ) to the PSUB service that includes the batch job ID and the primary key to the RXC.BATCH_JOBS table.

When the process receives the message, it:

• Reads the job information from the RXC.BATCH_JOBS table

• Creates a subdirectory named with the batch job ID under the user-specific subdirectory; see Securing PSUB

• Submits the job on the user's behalf with the PSUB Launcher (PSLAUNCH)

• Places the following files in the batch ID subdirectory, as required, where nnnn represents the batch job ID.:

  • lnnnn.log: Log file of a user's PSUB job. Note that the initial character is the letter L, not the number one.

  • onnnn.out: Output from a report job.

  • pnnnn.log: Log file for a print request from the Submitted Batch Jobs form.

• Copies the files to a database table BATCH_JOBS_LOBS, in a column with the CLOB data type. You can choose to delete the files from the temporary directory or not by setting OCL_STATE reference codelist value PSUB_DEL_FILES.

For more information , see:

• Asynchronous PSUB Requests
  
• Blocking and Nonblocking Jobs
  
• Checking a Nonblocking Batch Job
  

Asynchronous PSUB Requests

The Oracle Advanced Queue (AQ) mechanism is an asynchronous protocol, so messages remain in the queue until read by the process. This means that if a user makes a PSUB request and the process is not running, the request is read when the process is started again. Also, the DBA can safely stop and restart the process in a production environment, provided the delay is not too long. All nonblocking requests are processed, and all blocking requests start when the process comes up. You may have to resubmit the blocking job if you stop the PSUB process (daemon) while the blocking job is running.

Blocking and Nonblocking Jobs

Blocking jobs are usually of short duration and run in a mode where the system does not allow the user to proceed before their completion. Job completion status (SUCCESS or FAILURE) can be reported to the user immediately after the job completes. Blocking jobs in Oracle Clinical include:

• Default layout generation

• Moving a data entry screen to production

• Generating a Validation Procedure

Nonblocking jobs include all reports, all jobs launched from the PSUB submission screen, and randomization.

When an application server submits a blocking job, it sends information through an entry in AQ through client_send method then waits on an application server-specific AQ server_recieve method for completion (execution) information, which it receives from PSUB. The pipe is maintained by the application and is named with a unique session name.

Checking a Nonblocking Batch Job

Users are not notified when nonblocking batch jobs complete. To check the job's status, they can execute a query in the Submitted Batch Jobs form, accessible via:

• the Job Status button in the Submission of module window

• the Batch Jobs item from the Action in-form menu

• this command, entered from the opapps or system manager account:

  $ at -l