Batch Failures (.err Files)

When a Pro*C batch job fails during the overnight run, it usually throws a very generic error to the scheduling tool (like "Exit Code 1"). To find out what actually happened, you must check the error files.

By default, RMS Pro*C batches write errors to the directory defined in the $ERROR_DIR environment variable.

1. Locate the file: [batch_name]_[thread].err (e.g., saldly_1.err).
2. Open it to find the specific Oracle ORA- error or the business logic failure (e.g., "Item 1001 does not exist on ITEM_MASTER").

RIB Failures (Hospital Tables)

When a RIB message fails to process in RMS (e.g., a SIM message tries to update an item that hasn't been created in RMS yet), the RIB does not crash. It routes the message to the RIB Hospital.

The Hospital Flow:

1. Check the RIB_MESSAGE and RIB_MESSAGE_FAILURE tables (or use the RIB Hospital Admin UI/RIHA).
2. You will see the exact XML payload that failed and the Oracle error message.
3. Fix the data: If the item was missing, create the item in RMS.
4. Retry the message: Use the Hospital UI to click "Retry". The RIB will attempt to process the exact same XML payload again.

Tracing PL/SQL

If a custom batch or an RMS API is running terribly slow, or throwing an error deep within a 10,000-line package, you need to trace it.

Oracle provides standard tools like DBMS_PROFILER or SQL Tracing (ALTER SESSION SET SQL_TRACE = TRUE).

For application-level debugging, RMS has a built-in logging framework in some APIs. However, for deep database debugging, rely on the V$SESSION and V$SQL views.

SELECT 
    s.sid, 
    s.serial#, 
    s.status, 
    s.blocking_session,
    q.sql_text
FROM 
    v$session s
LEFT JOIN 
    v$sql q ON s.sql_id = q.sql_id
WHERE 
    s.username = 'RMS_USER'
    AND s.status = 'ACTIVE';

If blocking_session is populated, you have a lock contention issue—often caused by a developer forgetting to COMMIT after testing an update, or a custom package missing a FOR UPDATE NOWAIT clause!