Oninit® Logwalker — Operations

Logwalker is a single command-line binary. There is no daemon, no configuration file, no state directory; every invocation is one walk of one log uniqid with the flags you pass on the command line. This page documents the flags and the runtime contract; the Output Schema page documents what each line of the resulting text stream means.

Synopsis

logwalker -n <uniqid> [options]                              # walk one log
logwalker -t <db:table|partnum> --from-time <dt> [options]   # track one object over a date window
logwalker -t <db:table|partnum> --from-log <id> [options]    # track one object over a log range
logwalker -n <uniqid> --chunk <file> --start <b> --length <b> \
          --truncate-at <dt> --truncate-out <file> [--keep-tail]   # cut an offline log at a point in time

Command-line flags

Transaction boundaries in track mode

A track walk filters to the records that carry the tracked partition, so on its own it shows that a row changed — an HINSERT, an HDELETE — but not whether the change persisted. An INSERT whose transaction never reached a COMMIT (or that ended in a ROLLBACK) was undone; the bare record can't tell you which. Because BEGIN / COMMIT / ROLLBACK records carry no partition number, the plain filter would drop exactly the context you need.

So in HUMAN and --group-by-xid output, track mode passes through the boundary of every transaction that touches the object. The first time one of a transaction's records matches, logwalker prints an opening marker carrying the BEGIN's pid, uid and start time; when that transaction commits or rolls back, it prints a verdict:

=== TX 4812 opened on coris.sysprocedures  (pid=73628 uid=1000  began 06/16/2026 14:02:11) ===
LSN 480661:0x00000080  xid=4812  INSERT into coris.sysprocedures (rowid 0x00000101, 64 bytes)
=== TX 4812 COMMITTED @ 06/16/2026 14:02:11  — 1 tracked change(s) PERSISTED ===

=== TX 4815 opened on coris.sysprocedures  (pid=73630 uid=1000  began 06/16/2026 14:02:14) ===
LSN 480661:0x000001dc  xid=4815  DELETE from coris.sysprocedures (rowid 0x00000090)
=== TX 4815 ROLLED BACK  — 1 tracked change(s) DISCARDED (did NOT persist) ===

At the end of the walk a one-line summary tallies the transactions seen (committed, rolled back, open). Any transaction still open — one that touched the tracked object but whose COMMIT or ROLLBACK lies beyond the walked range — is flagged explicitly, because its persistence is genuinely unknown until you walk far enough to see its fate:

# ----------------------------------------------------------
# transaction summary: 1 committed, 1 rolled back, 1 open
# WARNING: 1 tracked transaction(s) had NO COMMIT/ROLLBACK in
#   the walked range — persistence UNKNOWN. Extend --to-log to
#   see their fate:
#   TX 4820  2 change(s)  (pid=73641 began 06/16/2026 14:02:20)

The fix for an open transaction is simply to widen the range (raise --to-log, or drop it so the walk runs to the last log on disk). If the BEGIN itself fell before the start of the range, the opening marker says (BEGIN before walked range) rather than inventing a timestamp. The --compat onlog format is left untouched — it stays a pure six-column stream for scripts that parse it.

Point-in-time recovery

Point-in-time recovery — stopping an ontape restore at a chosen commit time — has its own page with a worked example, the layout of filtered backups, and the sidenav for the whole topic: Point-in-time recovery. The flags it uses are listed in the table above.

• Cut a log backup (--truncate-at, --truncate-out, --keep-tail)
• Backups written with a BACKUP_FILTER (--restore-filter, --backup-filter, --tape-block)
• Stopping a restore with a restore filter (--pit-filter)

Pre-flight gates

Before the walk begins, logwalker enforces three gates and refuses to start with a [CRITICAL] diagnostic if any fail:

• sysmaster connect — if the ESQL/C CONNECT to sysmaster fails, the deployment-constraint reminder is printed and the binary exits non-zero. This catches the common "wrong INFORMIXSERVER" / "wrong INFORMIXSQLHOSTS" mistake.
• uniqid resolve — the requested uniqid must exist in the current syslogs view. Archived-and-recycled uniqids and never-existed uniqids both fail here.
• chunk R_OK — every chunk path in the resolved extent map for the uniqid must be readable by the OS user running logwalker. If any one chunk fails access(R_OK), the binary refuses with the deployment-constraint reminder. No partial walks; either the operator can read every chunk in the extent map or the walk doesn't start.

Catalog phases

Two catalog-load phases run at startup, sequenced to amortize their cost differently:

• Phase 1 (names only) — walks sysmaster.systabnames in one read. Builds a partnum → (dbname, owner, tabname) lookup covering every named partition on the instance (tables and indexes both; systabnames is the unified pseudo-view). Single connection, ~2–3 seconds on a 2K-partition instance. Auto-loaded for HUMAN and GROUPED modes so partnums render as their <db>.<table> names; skipped for --compat onlog (whose output has no name slot).
• Phase 2 (column maps) — gated on --decode-rows. For each unique dbname collected in phase 1, opens a separate ESQL connection and pulls syscolumns ORDER BY colno into the table's column list. Cost is proportional to the number of databases, not the number of tables; closes each connection before the walker starts emitting records. Databases the running user can't CONNECT to are logged as warnings (SQLCODE -387 / -329 / -23197) and their tables' rows render as hex rather than decoded values.

Exit codes