The problem at the boundary

IBM i middleware that bridges core systems to external HTTP clients sits on a critical trust boundary. Closed-source middleware products ask security teams to certify that boundary on vendor assurances alone — no code review, no static analysis, no independent verification. In regulated environments subject to PCI-DSS, SOX, HIPAA, FFIEC, FedRAMP, CMMC, or DISA STIGs, that gap is increasingly difficult to defend. A SOC 2 report and an NDA-gated code-review appointment where no notes are permitted are not the same as a reproducible, auditor-readable verification. Your certification rests on trust in the vendor, and cannot be independently reproduced.

ZCOMX is built on the opposite premise: the code your auditor reads is the code that runs.

Zero program modification — a design principle, not a feature

ZCOMX is specifically designed to require no source code changes and no recompiles to any existing IBM i program. Ever. Programs written in RPG, COBOL, CL, or C run exactly as they are today. Nothing about them changes when they are exposed as HTTP endpoints.

All operational control lives on the server side, in configuration. How a program is called, what parameters it receives, what data types those parameters use, what authentication is required, which IP addresses are permitted, whether the payload must be encrypted, how the response is mapped back to JSON — all of it is defined in the ZCOMX configuration file, invisible to the requesting client.

The client sends plain JSON. It has no knowledge of:

• The language the backend program was written in
• Whether parameters are packed decimal, zoned, fixed-length character, or binary integer
• The actual program name, library, or calling convention
• Whether an alias is in effect, routing the request to a different program entirely
• What authentication scheme is being enforced for that specific transaction
• What IP restrictions are applied

This means the system operator has fine-grained, centralized control over every aspect of how the IBM i estate is exposed — without touching a single line of production program code. Adding a new endpoint, changing a parameter mapping, tightening access to a specific transaction, or rerouting a call to a different program library are all one-line configuration changes. No development cycle, no recompile, no redeployment of the called program, no coordinated change across clients.

It also has a security implication: a client cannot probe the backend structure because it has no visibility into it. The calling mechanism is a server-side secret.

Designed for the AI era

ZCOMX has been designed from the ground up as an AI-forward product. This is not a feature added after the fact — it is a deliberate design assumption that the operators, auditors, and developers working with ZCOMX will use AI agents as a natural part of their workflow.

AI-assisted code audit. The source-available model is the foundation. An AI agent can read every line of ZCOMX — authentication logic, cryptographic key handling, request parsing, the audit trail — and answer specific questions about how the system behaves. A CISO asking “show me every place a credential touches memory and confirm it is zeroed” gets a precise answer from the code, not from a vendor datasheet.

AI-assisted configuration. ZCOMX configuration can be complex — transaction mappings, authentication schemes, encryption keys, IP restrictions, XMLSERVICE typed-parameter maps. ZCOMX ships with a built-in CLAUDE.md file that serves as a comprehensive context document for AI agents. When an operator asks an AI agent to generate a configuration block for an IBM i program, or to explain what a particular map definition does, or to recommend the right authentication scheme for a deployment, the agent has the full architectural context it needs to answer correctly. The CLAUDE.md is maintained alongside the source code and covers configuration options, security constraints, calling conventions, and known pitfalls — exactly the knowledge an AI agent needs to give reliable recommendations rather than plausible-sounding guesses.

AI-assisted customization and understanding. For organizations that exercise their right to modify ZCOMX for internal use, AI agents dramatically reduce the barrier to doing so safely. The same CLAUDE.md that guides configuration assistance also guides code-level changes — an agent asked to add a new authentication scheme or extend a transaction type has the full context of the architecture, the ILE C constraints, the IBM i-specific patterns, and the explicit list of things not to change and why. Source-available code that an AI can read and reason about is a fundamentally different proposition from source-available code that requires a human expert to navigate.

The MCP connection. ZCOMX’s Model Context Protocol support means the same IBM i programs it exposes as REST endpoints are immediately available as tools for any AI agent. The AI-forward design runs in both directions: AI helps operate and configure ZCOMX, and ZCOMX connects AI to IBM i.

Who does the integration work

The most common response when a CISO asks about replacing middleware is: “Our AS/400 developer(s) are fully booked. We don’t have the bandwidth for that kind of project.”

With most middleware changes, that objection is legitimate. Replacing the layer that calls IBM i programs typically requires someone who understands the program interfaces — packed decimal field widths, fixed-length parameter layouts, COBOL copybooks — to map those interfaces into the new system. That is IBM i developer work, and IBM i developers are in short supply.

ZCOMX is different in one specific way: the person who implements it does not need to be your IBM i developer(s). They need two things:

• A basic understanding of what each program does and what data it works with
• Comfort using AI tools

The rest is handled by AI. ZCOMX ships with a comprehensive context document (CLAUDE.md) that gives an AI agent complete architectural knowledge of the system. Point an AI agent at the RPG, COBOL, or CL source for a program and ask it to generate the ZCOMX configuration — it reads the parameter layout, identifies field types, selects the appropriate calling convention, and produces a ready-to-use configuration block. The IBM i developer(s) do not need to be in the room.

What the implementer actually does: - Identifies which programs need to be exposed as HTTP endpoints - Feeds source files to an AI agent - Reviews and validates the generated configuration - Tests the endpoint

This is JSON editing and AI-assisted verification — skills any modern developer or systems integrator already has, regardless of IBM i background. Adding a new endpoint after go-live is a configuration change, not a development project.

The IBM i developer(s)’ role does not change. They continue maintaining and extending the programs themselves. The integration layer is no longer their problem.

Architecture

[External Client]
    ↓  HTTPS/TLS
[NGINX reverse proxy on IBM i]
    ↓  Unix domain socket (AF_UNIX, 0660 permissions)
[ZCOMX worker pool — 20–30 concurrent workers]
    ↓  IBM i Machine Interface CALL PGM()
[IBM i programs — RPG, COBOL, CL, C — unchanged]

Each layer is independently auditable. NGINX handles TLS termination using standard, human-readable configuration — auditors can verify cipher suites, certificate management, and protocol version constraints directly. The domain socket is a local OS pipe with filesystem permissions; there is no network hop between NGINX and ZCOMX, eliminating an entire class of interception risk. Workers are pre-forked ILE C processes, each an independent IBM i job with isolated static storage, its own spoolfile, and no shared mutable state. The IBM i programs they call are existing production code that has not been modified or recompiled.

IBM i as a routing hub

ZCOMX is more than a REST adapter for existing programs. It is a routing layer — one that makes IBM i the integration hub for both inbound and outbound calls, all under a single authentication, audit, and access-control regime.

[External Client — web app, mobile, AI agent, partner system]
    ↓  HTTPS/TLS  (single endpoint)
[NGINX → ZCOMX worker pool]
    ├─ CALLPGM / CALLSRVPROC  →  IBM i programs (RPG, COBOL, CL, C)
    ├─ GETFILE / PUTFILE       →  DB2 for i, IFS, QSYS physical files
    └─ CALLHTTP                →  External REST APIs (cloud, SaaS, microservices)

The client sends a JSON request to a single endpoint. ZCOMX looks up the transaction name in its configuration and routes the call to wherever that transaction is configured to go — an IBM i program, a database query, or an external REST API. The client has no knowledge of the destination, the credentials in use, or whether the backend is local or remote.

The routing decision is a one-line configuration change. A transaction named GETCUSTOMER can point at an RPG program today and an external REST API tomorrow. The client code is unchanged. Authentication requirements, IP restrictions, audit trail, and duplicate detection apply identically either way. This is not a feature added for migration scenarios — it is a structural property of how ZCOMX works.

Credentials stay on IBM i. External API keys and bearer tokens are stored in IBM i *DTAARA objects, not in client applications or configuration files accessible outside the system. ZCOMX resolves them per-request, zeroes them from memory before returning, and logs the call without the credential. A compromised client application cannot retrieve the key it is using.

One audit trail covers everything. Every transaction — whether it calls a local RPG program, queries DB2, or reaches an external SaaS API — produces the same ZCOMLOG record: authenticated user, source IP, transaction name, target, timing, input, output, and success/failure. There are no unlogged calls and no second audit system to maintain.

For organizations in the middle of a workload migration — moving some transactions from IBM i to cloud services while others remain on-premises — ZCOMX functions as stable ground. The integration boundary does not move when the backend does.

What ZCOMX routes to

ZCOMX supports seven transaction types, covering local IBM i programs, file and database operations, AI tool calls, and outbound calls to external APIs. All routing is configured server-side; clients see only a JSON request and a JSON response.

Program calls (CALLPGM). Calls any IBM i *PGM object — ILE or OPM, written in RPG, COBOL, CL, or ILE C. No recompile, no PCML, no source language requirement. Three calling conventions are supported:

• Single-parameter — the program receives and returns a single fixed-length character buffer up to 32,767 bytes. The same buffer carries the request in and the response out. Suitable for the vast majority of existing IBM i programs without any modification.
• Three-parameter — the program receives the data buffer plus two output parameters: a single-character success flag (1/0) and a 132-byte error message field. Provides a clean separation between business data and error status. Recommended for new programs.
• JSON passthrough — parmdata is a JSON object; ZCOMX serializes it and passes the JSON string directly to the program. The program handles its own JSON parsing. No mapping configuration required.

Service program procedure calls (CALLSRVPROC). Calls a named procedure in an IBM i *SRVPGM object. Supports both simple character-buffer interfaces and fully typed parameters via XMLSERVICE — packed decimal, zoned decimal, binary integers, unsigned integers, boolean, and character fields of any declared length, with explicit in, out, both, and return directions. Procedures that return pre-built JSON strings (common with DB2 JSON functions) are supported directly. Type specifications live in server-side configuration; the client sends plain JSON field names and values.

Outbound HTTP calls (CALLHTTP). Makes an authenticated, audited outbound HTTP or HTTPS call to an external REST API and returns the response. The client POSTs to /CallHttp with a transaction name and a payload — ZCOMX looks up the configured target URL, resolves any API credentials from IBM i *DTAARA objects, makes the call, and returns the remote response. The routing hub section above covers the integration platform use case in detail.

File read (GETFILE). Returns file content as a JSON array. Three sources are supported:

• IFS files — reads any file in the IBM i Integrated File System with full EBCDIC/ASCII conversion
• QSYS physical file members — reads from traditional LIB/FILE(MBR) paths
• SQL — executes a SELECT statement or stored procedure call against DB2 for i and returns the result set. Dynamic SQL can be enabled for authenticated clients; stored procedure calls are the default. Empty result sets return HTTP 200 with an empty array — not an error.

File write (PUTFILE). Writes content to an IFS path or a QSYS physical file member. Supports append and overwrite modes. IFS writes handle CCSID translation automatically.

Health check (HEALTH). An unauthenticated endpoint that returns server status — worker identity, uptime, and configuration state. Designed for load balancer health probes and monitoring systems. The only endpoint that bypasses authentication by design.

Model Context Protocol (MCP). Accepts JSON-RPC tool calls from any LLM with an MCP connector and routes them to the configured IBM i program or service procedure. Uses the same transaction definitions, authentication, and audit trail as REST clients. Described further in the AI and MCP integration section below.

What auditors can verify

Authentication. All supported schemes — Basic/AS400, LDAP, static bearer token, HMAC-SHA256 signed bearer, and pluggable custom schemes — are implemented in readable ILE C. Every authentication decision is reachable from a single source file. Authentication ordering, cache behavior, credential length limits, and the signed-token format are all inspectable.

Program execution authority. When profile impersonation is enabled, ZCOMX swaps the worker job to the authenticated user’s IBM i profile before calling the backend program. The called program runs under that user’s object-level authority — its access to DB2 tables, IFS files, and IBM i objects is governed by standard IBM i security, not a shared service account. This is verifiable in the ZAUTHPRF CL module source. Workers run under a dedicated service profile by default; impersonation is opt-in per authentication scheme.

Cryptography. The recommended deployment terminates SSL/TLS at NGINX, which typically runs on the IBM i partition itself — keeping encrypted traffic decrypted only within the partition boundary. This uses standard, well-understood TLS configuration that auditors can verify directly against the NGINX config file.

As an option for environments where TLS is unavailable or impractical — air-gapped networks, constrained IoT devices that cannot perform a full TLS handshake — ZCOMX supports application-level AES-128 or AES-256 payload encryption as an additional layer. AES encryption and HMAC-SHA256 token signing use IBM i’s native QC3 cryptographic APIs. Key material is held in *DTAARA objects and resolved at call time — not stored in worker memory for the process lifetime. Keys are zeroed from memory before each function returns using volatile-pointer writes that cannot be eliminated by the compiler optimizer. The IV construction contract (session-GUID derived, fresh per request) is documented and verifiable.

Audit trail. Every transaction is written to the ZCOMLOG physical file with user profile, source IP, program called, timing, success/failure, error codes, and optionally full input/output payloads. The audit trail cannot be suppressed by client behavior; it records rejected requests as completely as successful ones. ZCOMLOG can be queried with standard IBM i database tools or any SQL client.

Whitelist and access control. IP allowlists and per-transaction restrictedto restrictions are enforced in code auditors can read, before any program is called.

No hidden channels. Worker source contains no outbound network calls outside the authorized request/response path. There is no telemetry, no phone-home, no update mechanism.

Security testing completed

ZCOMX has been subjected to multiple rounds of security testing across the following categories:

• API fuzz testing — schema-driven automated generation of boundary, malformed, and unexpected inputs across all endpoints
• Header fuzz testing — systematic fuzzing of HTTP header parsing, including oversized values, encoding variants, and injection attempts
• AI-driven edge case analysis — security review using the latest frontier AI models to identify logic gaps, boundary conditions, and vulnerability classes not covered by automated tooling
• Static analysis and source scanning — automated scanning of the full source tree for common vulnerability patterns
• Manual code review — focused review of authentication, cryptographic key handling, input validation, and the request parsing pipeline

What the testing covers: the attack surface available to an authenticated caller, plus unauthenticated boundary conditions at the HTTP parsing layer.

What it does not cover: authentication bypass, privilege escalation between users, IBM i CCSID and ILE exception edge cases, encryption key management, configuration security, and the behavior of customer programs called via CALLPGM. Those areas remain for your own assessment.

How it differs from the alternatives

IBM Integrated Web Services (IWS). IWS generates SOAP/REST endpoints by reading PCML parameter metadata from compiled program objects. This creates three operational constraints: programs must have been compiled with specific debug options; interface changes require re-running a wizard, regenerating a WSDL, and redeploying; and CL programs cannot be exposed at all — CL has no PCML support, so IWS requires a thin RPG or COBOL wrapper around every CL program. In the largest ZCOMX production deployment, approximately 98% of calls go to CL programs. ZCOMX uses the IBM i Machine Interface CALL PGM() — language-agnostic, working on any *PGM object regardless of source language, compile options, or age, with no wrappers and no wizards.

XMLSERVICE-based client tools (itoolkit, iService, custom wrappers). These require the calling application to supply IBM i data types — packed decimal field widths, zoned lengths, binary integer sizes. The client must know the backend structure. When a program interface changes, every client changes. ZCOMX inverts this entirely: parameter types, field lengths, and calling conventions live in server-side configuration. The client sends plain JSON and knows nothing about the backend. A program interface change is a one-line server config edit; no client is notified, updated, or redeployed.

Handler-code frameworks. Writing HTTP endpoints as RPG procedures requires mid-to-senior free-format RPG skills for each endpoint — procedure interfaces, ILE binding, the framework’s handler API. Every new endpoint is custom code. That skill set is retiring faster than it is being replaced; the average RPG developer is in their late 50s and computer science programs do not teach RPG. In five to ten years, an RPG-handler-based system becomes progressively harder to extend without expensive contractors. ZCOMX requires no RPG to operate: adding an endpoint means editing a JSON config file that any developer familiar with JSON can manage. The existing IBM i programs run unchanged.

AI and MCP integration

ZCOMX implements the Model Context Protocol (Streamable HTTP, 2025 revision), allowing any LLM with an MCP connector to call IBM i programs as tools — with no additional configuration. The same transaction definitions, authentication schemes, audit trail, and IP restrictions that govern REST clients govern AI clients identically. An IBM i program callable via REST is immediately available as an MCP tool. There is no separate tool inventory, no additional trust boundary, and no program modification required. The LLM is just another authenticated client; the audit log entry for an AI-driven call is indistinguishable from one made by a web application.

Outbound routing — CALLHTTP

ZCOMX makes outbound HTTP and HTTPS calls via IBM i’s Axis C transport library. Headers can carry literal values, IBM i *DTAARA references (resolved and zeroed per-request), forwarded inbound headers, or ZCOMX-internal context via @VAR: built-in variables — session GUID, authenticated username, client IP, and transaction name (@VAR:GUID, @VAR:USER, @VAR:IP, @VAR:TRX) — enabling correlation and identity forwarding to remote APIs without client involvement. TLS uses DCM application IDs — standard IBM i certificate management, no external keystore. Timeouts are configurable server-side; the client has no control over transport parameters.

Response handling:

• 2xx + JSON body — passed through verbatim with the remote status code
• non-2xx + JSON body — remote JSON embedded in a ZCOMX error envelope
• non-JSON body — ZCOMX error envelope with a body snippet for diagnosis
• Transport failure or timeout — ZCOMX error envelope; remote body captured in ZCOMLOG regardless

Every outbound call is logged in ZCOMLOG with the target URL, outbound body, remote response, HTTP status code, and outcome. A transport failure is as fully auditable as a successful 200.

Authentication, IP whitelisting, and duplicate detection apply to the caller of /CallHttp in exactly the same way as any other ZCOMX transaction. The outbound call is made under ZCOMX’s authority; the caller’s credentials govern access to the transaction, not to the remote API.

Compliance alignment

ZCOMX is designed to support — not replace — your existing compliance program. Source availability at the middleware boundary addresses specific control requirements that closed-source products cannot satisfy:

• Third-party software inspection — source is available for review, static analysis, and scanning without vendor involvement
• Cryptographic module verification — IBM i’s QC3 APIs are IBM-native; implementation is readable; key handling is auditable
• Audit trail completeness — every transaction recorded, including authentication failures and rejected requests
• Operational customization — for internal use, organizations can modify and patch ZCOMX without waiting for a vendor release cycle

Licensing

ZCOMX is source-available under a commercial license. Licensees have full rights to use, modify, deploy, and internally review the source code, including security audit and operational customization within their own organization. Redistribution and incorporation into other products or projects are not permitted.

Contact

Bill Herron — bill.herron@zanden.com

Operations guide, security rationale document, and auditor brief available on request.