What it Does

An external client — a web application, a mobile app, a partner system, or an AI agent — sends a plain JSON request to a single HTTPS endpoint. ZCOMX authenticates the caller, checks it against the permitted source addresses, looks up the requested transaction in its configuration, and routes the call to wherever that transaction is defined to go: an IBM i program, a DB2 query, a stored procedure, a file, or an external REST API.

​​

The result comes back as JSON. Every step is written to an audit log.

​

The client never learns what is behind the endpoint. Program names, library names, parameter layouts, field types, and calling conventions are all server-side configuration. A client cannot discover them, and a compromised client cannot probe for them.

Exposing Endpoints

This is the part that surprises people, so it is worth being precise about.

IBM i programs receive parameters in fixed layouts — packed decimal fields, zoned decimal, fixed-length character buffers, binary integers. Modern clients send JSON. Something has to translate between the two.

​

Most approaches solve this by changing something on the IBM i side: recompiling the program to emit metadata, or writing a wrapper program that speaks JSON, or hand-coding an HTTP handler for each endpoint.

Mapping Transactions

ZCOMX puts the translation in configuration instead.  A *map* describes how JSON field names correspond to the program's parameter layout — which field goes where, how long it is, what type it is, whether it is required, and what validation applies. The map lives on the ZCOMX server. The program is never touched, never recompiled, and never knows it was called over HTTP.

​

The practical consequences:

​

Any program object works — ILE or OPM, written last week or in 1989, in RPG, COBOL, CL or C

CL programs work directly. This is unusual. IBM's own Integrated Web Services relies on PCML metadata, which the CL compiler does not produce, so CL programs cannot be exposed without writing an RPG or COBOL wrapper around each one. ZCOMX calls CL directly

Interface changes are a config edit, not a client-wide redeployment.  A program can be renamed, moved to another library, or rewritten behind a stable API

Configuration as Source of Truth

Everything ZCOMX does is governed by one artifact. The configuration declares which endpoints exist, which programs and libraries they reach, which fields a client may send, how those fields are validated, which callers are permitted, which authentication applies, and which values are redacted from the log.

​

Nothing outside that configuration is reachable, and the runtime reads exactly those files. There is no second description that can drift out of step with what is actually running.

​

For a security team this has a specific value: **the total exposed surface is a single reviewable document.** It can be diffed, version-controlled, reviewed by someone who has never signed on to an IBM i, and signed off. Approving the configuration *is* approving the boundary. The OpenAPI specification published to client developers is generated from that same file, so what the auditor approves and what the client integrates against are the same thing.

What ZCOMX connects to

Eight transaction types, all configured the same way, all sharing the same authentication, access control, and audit trail.

​

Call an IBM i program — any `*PGM` object, ILE or OPM, in any language. Single-parameter, three-parameter, and JSON-passthrough calling conventions are supported.

​

Call a service program procedure — with fully typed parameters: packed decimal, zoned, binary and unsigned integers, float, varchar, boolean, character fields, and arrays and data structures, including nested ones.

Call a DB2 stored procedure — with typed `IN`, `OUT`, and `INOUT` parameters, including CLOB parameters for procedures that take or return large JSON documents.

​​

Query the database — a `SELECT` statement or stored procedure call against DB2 for i, returned as a JSON array. No program required.

​​

Read and write files — both the Integrated File System and traditional QSYS physical file members, with EBCDIC/ASCII and CCSID conversion handled automatically. This gives an authenticated, audited, HTTP-based alternative to FTP.

​​

Call an external REST API — outbound HTTP or HTTPS to a cloud service, SaaS platform, or microservice, with credentials held in IBM i data areas rather than in client applications, and every call logged like any other transaction.

​

Serve AI agents over the Model Context Protocol — every program already configured as a REST endpoint is automatically available as an MCP tool. There is no separate tool inventory to define.

​​

Health checks — for load balancers and monitoring.

Security Properties That Matter

The source code is available.  Every line handling authentication, cryptography, request parsing, routing, and logging can be read by your security team, your auditors, or a static analysis tool. Middleware at a trust boundary is exactly where "trust the vendor" is hardest to defend, and source availability replaces that with verification.

​

Every transaction is logged — and sensitive fields can be redacted.  ZCOMX writes each transaction to a standard IBM i physical file: who called, from where, what was called, how long it took, whether it succeeded, and optionally the full request and response payloads. Nominated fields — card numbers, national identifiers, credentials — are masked **in the log copy only**, while the real value still reaches the program and returns to the client. Redaction fails closed: if masking cannot be completed, the audit field is written blank and an alert is raised, never

written in the clear.

​

That combination is what makes a payload-level audit trail usable under PCI-DSS, HIPAA, or GDPR instead of becoming regulated data in its own right.

​

Multiple authentication schemes, enforced per transaction.  Native IBM i profiles, LDAP and LDAPS, static bearer tokens, HMAC-signed tokens, and RS256 JWT validation against an external identity provider such as Entra ID, Okta, or Auth0. Users with no IBM i profile can be authenticated without one being created for them.

No foreign runtimes.  ZCOMX is native ILE C. There is no Java Virtual Machine, no PASE environment, no Node.js runtime, and no package dependency tree. The code an auditor has to review is the ILE C source plus three well-known open-source libraries. Products built on Node.js ask a security team to implicitly trust every package in a dependency tree that can run to hundreds.

​

No telemetry.  No phone-home, no usage reporting, no automatic update mechanism. The worker source contains no outbound network calls beyond the request/response path and whatever outbound API calls you configure — and that is verifiable in the source rather than promised in a datasheet.

​

Designed to work behind perimeter secured by NGINX. TLS termination, rate limiting, request size limits, and malformed request rejection are done by software that runs on hundreds of millions of sites and has a security track record auditors recognize on sight, rather than being reimplemented in application code.

How ZCOMX is Different

Products in this space fall into three groups, and ZCOMX sits outside all of them.

Metadata-driven tools, including IBM's Integrated Web Services, generate endpoints by reading parameter descriptions compiled into the program object. This works well for ILE programs that have that metadata. It also draws a hard boundary: IBM documents that the technology exposes Integrated Language Environment program objects, so OPM programs are excluded, and CL programs are excluded because the CL compiler produces no such metadata. The metadata format also cannot describe a procedure returning anything other than a 4-byte integer — IBM's compiler omits such procedures from the generated description entirely.

​

Handler-code frameworks ask you to write an RPG procedure for every endpoint. That is a real and reasonable approach for new development, but each endpoint becomes custom code, and it requires mid-to-senior free-format RPG skills — the scarcest and fastest-retiring skill set in the IBM i ecosystem.

​

Node.js-based gateways are configuration-driven like ZCOMX, but run in PASE, outside the ILE environment, and bring a JavaScript runtime and its dependency tree onto the system. They are typically not source-available.

​

ZCOMX is the only option that is simultaneously configuration-driven, native to ILE, and source-available — which is why it tends to be evaluated by security officers rather than by development managers.

What ZCOMX is Not

Being clear about the boundaries is more useful than claiming everything.

It is not a modernization platform.  It does not rewrite your programs, generate user

  interfaces, or move you off RPG. It assumes your programs are fine and that the problem is reaching them safely.

​

It is not an integration suite.  No EDI translation, no Kafka or event streaming, no SOAP, no managed file transfer. It does HTTP request/response in both directions, plus file access.

​

It is not a low-code tool. There is no drag-and-drop builder. Configuration is JSON files, reviewed and version-controlled like code.

​

It is not a development framework. You do not write applications in ZCOMX. It connects applications you already have.

Common Questions

Do I have to change my programs?

No. Not the source, not the compile options, not the parameter interfaces. This is a design constraint, not a default that can erode.

​

Does it work with OPM programs?

Yes. ZCOMX calls program objects through the IBM i Machine Interface, which does not distinguish between OPM and ILE.

​

Can it expose a CL program as a REST API?

Yes, directly, with no wrapper program. This is one of the clearest differences from

metadata-based approaches.

​

Who installs and operates it?

Not necessarily your IBM i developer. Adding an endpoint means editing a JSON configuration file.  Mapping configuration can be generated from program source by commands that run on the IBM i itself, so source code never has to leave your building.

​

What does an auditor get?

The full source code, a software bill of materials (CycloneDX), a documented security rationale, a published findings history, a static-analysis register, and a single configuration file that states the entire exposed surface.

​

Does ZCOMX bypass our exit point security?

No — but it is not directly covered by it either. Exit points govern the IBM i host servers: ODBC and JDBC, remote command, DDM, FTP, telnet. ZCOMX is none of those — it listens for HTTP and calls programs from its own job, so exit programs never see its traffic, as with any web application server on the partition, IBM's own included. It brings the equivalent controls in configuration instead: permitted addresses, accepted credentials, reachable programs, libraries, tables and directories, and a log of every transaction.  

​​

Has ZCOMX been independently penetration tested?

Not by a vendor-commissioned assessor. For source-available software at a security boundary, a customer-side assessment is stronger evidence — you choose the assessor, you scope it, and you can read the actual code rather than testing a black box. Closed-source alternatives cannot offer that at any price.

​

Does it support AI agents?

Yes, natively. ZCOMX implements the Model Context Protocol, so any program exposed as a REST endpoint is immediately callable as a tool by an LLM — with identical authentication, access control, and audit logging. The audit record for an AI-initiated call is indistinguishable in form from one made by a web application.

​

What does it run on?

IBM i 7.3 and later. Native ILE C, deployed behind NGINX on the same partition.