If you run Informix 4GL applications in production, you already know the two paths on offer. Rewrite the application — open-ended scope, new bugs, new edge cases, no guarantee the rewrite ever reaches parity. Wrap it in a screen-scraper — fragile, opaque, owned by a vendor whose roadmap is not yours. Neither path keeps the runtime you trust at the centre of the picture. Nexus does.
The daemon launches the 4GL under a PTY the same way a terminal session would. A reader thread drains the master side, the Informix-4GL adapter decodes the byte stream into screen transitions, and those transitions become frame deltas the browser paints. The 4GL never knows it is not talking to a terminal. There is no shim in the runtime path. The 4GL binary on disk is the 4GL binary that runs.
The daemon authenticates the user against the host account database (PAM-ready; a devfile backend ships for development), then forks, drops privilege to the authenticated user, opens the PTY, and execs the 4GL inside that user’s normal shell environment. The parent process never holds elevated privilege beyond the moment it needs to. Existing UNIX permissions gate access exactly as they would for an ssh login.
Every observed transition, every forwarded keystroke, every policy decision, every authentication outcome, every session lifecycle event lands in an append-only JSON Lines record stream — ten distinct event types covering the full session lifecycle. Audit failures are fail-stop by default: if the sink is unreachable, sessions stop accepting input until either the sink recovers or the operator explicitly authorises degraded operation. The shipped gs-replay tool reconstructs any audited session byte-for-byte — no “approximate” replay, no missing keystrokes, no off-by-one transitions.
Operator-configurable reconnect window: if the browser drops the WSS but the daemon survives, the 4GL process keeps running and the daemon buffers observed output. The user reopens the tab, replays the buffer, and resumes live observation. Daemon death is the boundary — there is no daemon-to-daemon session migration and no attempt at one, because the 4GL process state is not portable across hosts. Availability comes from running multiple independent daemons; sessions are sticky to the daemon that created them.
Daemon network bindings, TLS material paths, ciphersuite policy, authentication backend, adapter selection and version pin, per- application launch parameters, policy hook chains, audit sink configuration, reconnect window, session admission limits, logging verbosity — all in YAML, all validated on load. A daemon refuses a configuration that fails schema validation; the previous configuration stays live. CLI flags override YAML for ad-hoc overrides.
Three operator-facing tools ship with every daemon and gate behind YAML flags (default on, off-able for production):
You don’t have to recompile the 4GL. You don’t have to patch the runtime. You don’t have to migrate your schema. You don’t have to introduce a new database, queue, cache, or coordination service. You don’t have to change how host accounts work. The platform’s value is in what it preserves; the runtime stays where it is. Call +1-913-732-8892 (US) or +44-2081-337529 (UK), or email support.info@oninit.com — we can scope a working trial against one of your 4GL applications inside a week.
To discuss how Oninit ® can assist please call on +1-913-732-8892 or alternatively just send an email specifying your requirements.
You get all this for free.. think about what you get if you pay us