Oninit UDR / Informix DataBlade engineering
Talk to an expert →

Oninit® UDR — ONI UDR Debug

A generic, reusable diagnostic subsystem for C UDR code — one shared, structured record of what your UDRs actually did, built to never fail silently.

Why not mi_trace()?

The DataBlade tracing facility is available, and ONI UDR Debug can emit to it as an optional secondary sink, but it isn't the primary mechanism — and the reason isn't performance. It's that every one of its failure modes is silent:

  • a trace class not registered in systraceclasses produces no output and no error;
  • the trace file is established per session, so code running in a PER_SYSTEM or background context has no obvious destination;
  • DPRINTF may be compiled out entirely depending on build configuration, so identical source behaves differently between builds;
  • a wrong path or wrong permissions produces nothing, again without an error.

In every one of those cases the operator sees an empty file and has no way to tell which reason applies. ONI UDR Debug is built around the opposite principle: if something goes wrong, that failure itself is recorded and surfaced, never swallowed.

What it gives you

  • One shared queue, instance-wide. A single PER_SYSTEM circular message queue holds every session's records — no per-session trace files to hunt down, no missing context because a background VP had nowhere obvious to write.
  • Capture-scope filtering. Run wide open (system — every session) or scoped to just the sessions that opted in (session), with correlation IDs so interleaved records from concurrent sessions can be pulled back apart per request.
  • Truncation that tells you it happened. An over-length record is truncated, never silently split or dropped — and the truncation itself is flagged on the record, in the running counters, and in the dump output.
  • Flushing that survives disk trouble. Flushes trigger on queue occupancy, on age, or on demand, with a single flush owner at a time. A failing disk doesn't lose queued records — they stay in memory, readable, until the subsystem self-disables after a configurable run of consecutive failures rather than looping forever against a dead disk.
  • A full SQL admin surface. Turn it on, check status, ask why nothing is showing up, adjust a class's verbosity, force a flush — all from ordinary SQL, no shell access to the server required.
  • Generic by design. Not tied to any one UDR project's schema or business logic — link it into any C UDR module that needs a place to put diagnostic output.

From SQL

EXECUTE PROCEDURE oni_debug_on();

SELECT oni_debug_status() FROM sysmaster:sysdual;
SELECT oni_debug_why()    FROM sysmaster:sysdual;
SELECT oni_debug_dump()   FROM sysmaster:sysdual;

EXECUTE PROCEDURE oni_debug_queue_flush();
EXECUTE PROCEDURE oni_debug_off();

oni_debug_why() is the fast path when nothing seems to be happening — it answers, in one call, whether the subsystem is disabled, healthy and simply quiet, or self-disabled after flush failures, so there's never a guessing game about which of those it is.

Install & usage

Ready to try it? The install guide covers building the module, deploying it, and registering the SQL surface; the usage guide covers configuring it and using it day to day, with real worked examples.

Verified against a real instance

ONI UDR Debug isn't validated by compilation alone. Every part of it — the shared queue, the flush lifecycle, the PER_SYSTEM memory it runs in — has been built and exercised against a live, running IBM Informix Dynamic Server instance, end to end, not just checked against the SDK headers.