Oninit logwalker / Online-log analysis
Talk to an expert →

Oninit® Logwalker — --compat onlog output

For scripts and tooling that already parse the legacy onlog -l 6-column form, logwalker can emit that exact shape. Drop-in compatible: same header line, same column order, same hex-vs-decimal styling, same per-record-type tail extras. Default output stays the human-readable form; this mode is opt-in.

Invocation

$ logwalker -n 271 -m 12 --compat onlog

Output


log uniqid: 271.

addr     len  type      xid     id  link
18       56   BEGIN     31      271 0        05/06/2026 01:00:06 26847       informix
50       48   UNIQID    31      0   18       1007ef 883
80       236  HINSERT   31      0   50       1007ef 101 169
16c      64   ADDITEM   31      0   80       1007f0 1007f0 1007ef 1
1ac      48   UNIQID    31      0   16c      1007ef 884
1dc      236  HINSERT   31      0   1ac      1007ef 102 169
2c8      64   ADDITEM   31      0   1dc      1007f0 1007f0 1007ef 1
308      56   COMMIT    31      0   2c8      05/06/2026 01:00:06
1018     56   BEGIN     31      271 0        05/06/2026 01:00:06 26847       informix
1050     48   UNIQID    31      0   1018     1007ef 885
1080     232  HINSERT   31      0   1050     1007ef 103 168
1168     56   COMMIT    31      0   1080     05/06/2026 01:00:06

Reading it

The columns match the IBM onlog -l emission spec:

  • addr — log address in bare hex, no 0x prefix.
  • len — record length in bytes (decimal), including the 32-byte loghdr.
  • type — record-type name. Spelled the same way IBM’s tool does (BEGIN, COMMIT, HINSERT, HDELETE, HUPBEF, HUPAFT, ADDITEM, UNIQID, CHALLOC, CHFREE, PTEXTEND, PTRUNCATE, TRUNCATE, BEGCOM, ERASE, …). Unknown codes render as 0xHHHH.
  • xid — transaction id (decimal).
  • id — the id sub-field from the record header. For BEGIN this is the log uniqid; for most other records it is 0.
  • link — backlink to the previous record in the same transaction (LSN low half, in bare hex). 0 on a fresh BEGIN.
  • tail extras — per-type. BEGIN ends with MM/DD/YYYY HH:MM:SS pid username (username resolved from the body’s uid via getpwuid()); COMMIT ends with MM/DD/YYYY HH:MM:SS; HINSERT / HUPAFT / HUPBEF / HDELETE end with partnum rowid rowlen; UNIQID with partnum next_serial; ADDITEM with parent_part child_part rowid slot_len extra1 extra2; BLDCL with partnum n1 n2 n3 n4 table_name; CHALLOC / CHFREE with chunk:page n_pages; PTEXTEND with partnum n_pages chunk:page; ERASE with partnum; PTRUNCATE / TRUNCATE with partnum 0.

When to use it

The --compat onlog mode exists for one reason: existing operator tooling that already grep / awk / parse onlog -l output. If you have such tooling, pointing it at logwalker --compat onlog works without rewrites.

For new tooling, prefer the default HUMAN form — the LSN column is canonical Informix and the description column is unambiguous. The --group-by-xid form is the friendliest for incident review and audit because it surfaces transaction boundaries explicitly.

Address scheme caveat

For records that are part of the live link chain (every record onlog -l shows), logwalker’s addresses match onlog -l’s address column directly. On a recycled log file that still holds residual content from a prior log generation, logwalker walks the raw chunk bytes and may surface records onlog would skip (because onlog follows the link chain, not raw bytes). Within a single live transaction the BEGIN → COMMIT chain matches; record counts diverge at the inter-transaction layer on busy recycled logs.