Oninit® 4gl2everywhere — Decouple Compiled 4GL From the Informix Engine
Compiled Informix 4GL applications are tightly bound to the database they were built against — not at the source level, but at the wire-protocol level. 4gl2everywhere replaces the wire counterpart without touching the application binary.
Where it sits in the stack
4gl2everywhere is a TCP listener that accepts the Informix client protocol (SQLI) on the front end and dispatches to a configured target database on the back end. It runs as a normal Linux daemon, between the 4GL clients and whatever database the modern infrastructure provides. There is no application adapter, no client-side driver replacement, and no library to embed in the 4GL runtime.
Pluggable backend interface
A single backend interface lets each target database define its own semantics behind a uniform contract: connect, database open / close, execute, fetch, transaction control, and error mapping. The current backends — PostgreSQL, MySQL / MariaDB, Oracle, plus a built-in null mock for protocol bring-up — are runtime-selectable per listener. New backends are added by Oninit on customer request.
Translation through an open IR
SQL coming out of the 4GL client is parsed into an AST, lowered to a dialect-independent IR, and rewritten per target dialect before the backend executes it. The IR is the extension point: each backend adds a dialect-rewrite module rather than touching the parser. The pipeline is inspectable at every stage; SQL trace files record the per-session token stream for forensics and verification.
Multi-listener deployments
A single bridge process runs multiple listeners on different ports, each with its own backend, DSN, max-sessions cap, and optional log / sqltrace overrides. The listener block in the YAML config inherits log and sqltrace settings from the global block field-by- field, so cross-cutting changes are one-line edits and per-listener exceptions are explicit. Multi-listener is the natural shape for hybrid deployments — some 4GL clients pinned to Informix, others redirected to a modern backend, all under one process and one config.
Operational primitives that match production reality
One pthread per session with configurable session caps; signal- driven graceful drain on SIGTERM / SIGINT; SIGHUP runtime reload of logging and SQL trace; SIGPIPE ignored; no exit() in session threads — broken sessions cannot crash the listener. The error format on SQ_ERR is canonical IFXBRIDGE:CATEGORY:DETAIL so 4GL programs can match on category and operators can grep logs by category.
No application changes, no client redeploy
Because the bridge speaks the protocol the 4GL was originally compiled against, there is nothing to redeploy on the client side. The 4GL binary, its build chain, its development tooling, and the existing operational runbooks all stay as-is. The change is at the network and database layer, not the application layer.
Where it fits in a target architecture
- Database modernisation off Informix without freezing the compiled 4GL portfolio.
- Hybrid deployments — some 4GL applications on Informix, others on PostgreSQL / Oracle / MySQL — under one bridge process.
- Strangler-pattern migrations where new functionality lives on the modern database while legacy 4GL clients continue against a redirected backend.
- Pre-migration risk assessment using the null backend to verify protocol compatibility before committing to a target.