Zowe's Single-Service API ML Changes What Your AT-TLS Jobname Rules Match
Since Zowe 3.4.0, a new install runs the whole API Mediation Layer as one z/OS address space with the jobname suffix AG. AT-TLS picks which rule applies to a connection partly by jobname, so the switch changes what your existing policy matches. Here are the three rule shapes it affects, and a documentation error to avoid.
One JVM now answers for five API ML servers
Zowe 3.3.0 introduced single-service deployment of API ML, and the 3.4.0 installer enables it by default. The Gateway, Discovery Service, API Catalog and Caching Service run in a single JVM, in a single address space that listens on both 7554 and 7553 (single-service guide). ZAAS, the authentication service, is folded into the Gateway too (architecture overview), and the default ports 7552, 7555 and 7558 go unused (single-service guide).
In multi-service mode each of those servers had its own suffix: AG for the Gateway, AD for Discovery, AC for the Catalog and CS for Caching (architecture overview), with ZAAS on AZ. With the default prefix ZWE1, five names collapse into ZWE1AG.
This reaches teams who do not think of themselves as Zowe operators. IBM withdrew Data Studio support for Db2 for z/OS on 31 March 2025 (IBM), and at a Planet Mainframe user group session IBM's Joe Winchester said its replacement, the Db2 Administration Foundation, is built entirely on Zowe (Planet Mainframe). The same session covered Zowe 3.x's move from multiple address spaces to a consolidated model.
Why AT-TLS sees a jobname change as a policy change
A TTLSRule can carry a Jobname. When it does, IBM's reference says a packet must be flowing to or from an application with that job name for the packet to match the rule, and a trailing asterisk makes the name a wildcard (TTLSRule statement).
Ports, addresses and direction still narrow a rule. What disappears is the ability to write a rule for the Catalog's connections that excludes the Gateway's, because inside one address space they carry the same name.
Three rule shapes and what the switch does to each
Sort every rule in your PAGENT policy that names a Zowe jobname into one of these:
- Wildcards (
ZWE1*,ZWE1A*). Zowe's own sample rules use both, andZWE1AGsatisfies both (AT-TLS guide). These keep matching; only their port ranges need review. - Exact names for servers that no longer run (
ZWE1AZ,ZWE1AD,ZWE1AC,ZWE1CS). These now match nothing. The single-service guide singles out the outbound z/OSMF rule, which must move fromZWE1AZtoZWE1AG"as authentication may not work by default". - Exact rules for
ZWE1AG. These keep matching, and the traffic they cover has grown. A rule written for the Gateway alone now also applies to connections opened by Discovery, Catalog and Caching code in the same process.
The third shape is the one to audit hardest. Zowe warns that an outbound rule sending the Zowe server certificate to a southbound service which accepts X.509 client certificates authenticates the caller as the Zowe server user ID (AT-TLS guide). Any ZWE1AG rule that presents that certificate now presents it on behalf of more code than it did when it was written.
The architecture page names a suffix the code never sets
Zowe's architecture overview, last updated 18 August 2026, says the single-service server "uses the jobname suffix of GW", and repeats GW for the Discovery Service, Catalog and Caching Service.
The start script says otherwise. In zowe/api-layer, the single-service launcher sets APIML_CODE=AG and starts Java with _BPX_JOBNAME=${ZWE_zowe_job_prefix}${APIML_CODE} (start.sh at commit 50684ae). The single-service guide says ZWE1AG and prints sample log lines under it, and the single-service AT-TLS guide lists ZWE1AG for every API ML port. I checked all four on 24 September 2026.
A rule written as Jobname ZWE1GW fits IBM's one-to-eight-character rule for the name, and no Zowe process carries it. Take the name from the running address space, and treat the overview as wrong on this point until it is corrected.
Ports and log lines that move with the address space
Two more things change beside the rules:
- Infinispan ports. Single-service mode requires
infinispanstorage for the Caching Service, and Infinispan needs its own ports (single-service guide). Zowe's sample inbound rules give 7600 to 7601 a rule of their own and skip 7555 on purpose, which the guide says keeps the policy compatible with multi-service mode (AT-TLS guide). - Log prefixes. Discovery, Catalog and Caching messages now print under
ZWE1AG. Message codes such asZWEAM000Iare unchanged, and the change affects spool and USS logs only; WTOs are unchanged (single-service guide).
Automation that keys on the message ID survives the switch. Automation that keys on the jobname and the message together needs the new name.
What to change before accepting the 3.4 default
List every Jobname in your policy that starts with your zowe.job.prefix, and put each one in one of the three shapes above. Move the z/OSMF outbound rule to ZWE1AG, delete the rules for servers that no longer exist, and reread each exact ZWE1AG rule that sends a certificate. Then issue F PAGENT,REFRESH and restart Zowe, which the AT-TLS guide recommends to avoid problems with open connections.
Kubernetes is not supported in 3.4 single-service mode. You can go back by setting components.apiml.enabled to false, and Zowe says that option stays for the whole v3 lifecycle (single-service guide). Fix the policy before you set components.apiml.enabled to true on an existing install, and before a new 3.4 install starts for the first time.