The z/OS Interface Ecosystem: Bridging Networks, Security, Automation and Development
For the final installment of "z/OS and Friends," Joe Gulla catalogs the modern interfaces for networking and integration, security, monitoring and automation, and DevOps
Supplying the IT community with robust and useful interfaces is an awesome challenge. In the early days of mainframe computing, the interfaces were direct with a well-defined scope. You invoked a supervisor service, and when you did it right, your program continued to execute.
Of course, there was error handling for problem situations. You might want to review Chapter 8 in the current z/OS documentation, “Providing recovery,” for error handling. There are familiar pairs—GETMAIN/FREEMAIN, WAIT/POST, OPEN/CLOSE and ENQ/DEQ. I still think of these pairs as Jack and Jill, but programming in BAL was not the stuff of nursery rhymes.
Today’s multi-network, multi-OS, multi-platform, multi-everything IT world is significantly more complex, thus the requirement for effectively bridging networks and ensuring adequate security. This is the compelling reason for interfaces that handle interacting in these various systems and domains. These interfaces also support disciplines like automation and development. Automation and its interfaces arose because there were so many things to manage at the same time; it was beyond most humans’ ability to cope. Development interfaces arose mostly to improve the quality of services for application development and management—again, too much to do and keep track of for most human team. They needed help.
That is the background for this article, the second in this series focused on z/OS interfaces. The first article on interfaces focused on four areas: system programming interfaces, application programming interfaces, command-line interfaces and data access interfaces. This article, by contrast, includes a discussion of (1) network and integration interfaces, (2) security interfaces, (3) monitoring and automation Interfaces and (4) development and DevOps interfaces.
1. Network and Integration Interfaces
The size and diversity of networks has grown considerably over recent decades, requiring new ways to integrate and manage them. In response to this need, many interfaces were developed. The TCP/IP stack APIs are a stunning case in point.
The network and integration interfaces in this section focus in four areas: TCP/IP stack APIs, z/OS Connect EE REST APIs, WebSphere Application Server (WAS) interfaces and FTP/SFTP/NFS protocols.
TCP/IP stack APIs
The IBM z/OS TCP/IP stack provides a variety of APIs that allow applications to interact with the network stack for communication over IP. These APIs are part of the z/OS Communications Server and support different programming languages and environments. Table 1 lists the major APIs that are based on TCP/IP.
Table 1. Key TCP/IP Stack APIs Used by z/OS and Other Systems
| API Type | Description | Supported Languages and Environments |
| C Sockets API | Standard socket interface for C programs; similar to BSD sockets | C |
| Pascal API | Pascal-specific interface for TCP/IP communication provided by z/OS Communications Server | Pascal |
| CICS Sockets API | Allows CICS applications to act as TCP/IP clients or servers. | C, COBOL, PL/I, Assembler |
| IMS Sockets API | Enables IMS applications to communicate over TCP/IP | COBOL, PL/I |
| Sockets Extended Macro API (discussed in Native TCP/IP topic) | Low-level assembler macro interface with support for asynchronous processing. | Assembler |
| Sockets Extended Call Instruction API (discussed in Native TCP/IP topic) | High-level language interface resembling C sockets, with extensions | COBOL, PL/I, Assembler |
| REXX Sockets API (discussed in Native TCP/IP topic) | Allows REXX programs to use TCP/IP sockets | REXX |
| X/Open Transport Interface (XTI) | POSIX-compliant interface for transport layer communication | C (z/OS UNIX) |
| Network Management APIs | Used for SNMP and other network management tasks | Various |
| IP Resolver API | Provides name resolution services, for example, DNS lookups; there are many different tool implementations of this basic function. | All environments |
| Netstat and Ping APIs | Programmatic access to network status and diagnostics | Shell, REXX, C |
| FTP, Telnet, SMTP APIs | Interfaces for standard IP applications | Various |
| Remote Procedure Call (RPC) | For distributed application communication | C |
These APIs allow z/OS applications to open and manage socket connections, send and receive data over TCP/IP, resolve hostnames and manage IP addresses, integrate with distributed systems and web services and support modern DevOps and hybrid cloud architectures.
z/OS Connect EE REST APIs
IBM z/OS Connect Enterprise Edition (z/OS Connect EE) provides a powerful framework for creating and exposing REST APIs that allow contemporary applications to interact with long-standing z/OS assets that utilize CICS, IMS, Db2 and MQ. It’s a tool to create program-like APIs but it is not a programming language. Powerful tools like this are representative of the API economy.
z/OS Connect EE REST API Components
z/OS Connect EE doesn’t provide a fixed list of REST APIs like many web services. Instead, it enables developers to create custom REST APIs that expose (meaning make available) z/OS-based services. Using this product, APIs are defined and managed using the z/OS Connect API Toolkit, which supports service projects, API projects and API Requestors.
Service Projects
Service projects are used to define how z/OS programs written in COBOL, PL/I and other languages are exposed as services. Developers can create services for the following:
- CICS programs
- IMS transactions
- Db2 stored procedures or native REST services
- IBM MQ queues
API Projects
API projects are used to define REST APIs that map to the services created in service projects. Through projects, developers can:
- Define paths, query parameters, and headers
- Map these to fields in the JSON schema of the service
- Use the API Editor and Mapping Editor to visually design and test APIs
- Deploy APIs to z/OS Connect EE servers
- Test APIs using the embedded Swagger UI
API Requesters
With API requestors, z/OS applications including those written in CICS, IMS and batch, can also consume (make use of) external REST APIs using the API requester feature. This is done by:
- Importing an OpenAPI (Swagger) definition
- Generating an API requester archive (ARA) or WAR file
- Using generated COBOL or PL/I stubs to call the REST API from z/OS
Here is a table that summarizes the z/OS Connect EE REST API components.
Table 2. z/OS Connect EE Components, Role and Functions
| Component | Role | Key Functions |
| REST Client | Sends REST API requests and receives responses from z/OS Connect EE | Initiates HTTP requests, handles JSON payloads, consumes API responses |
| API | Defines the REST interface exposed to clients; maps requests to services | Provides OpenAPI definition, maps REST endpoints to backend services |
| API Request Processing | Handles request transformation, validation, and routing to backend systems | Converts JSON to COBOL/PL/I structures, validates input, applies data mapping |
| Service | Represents the backend resource like CICS, IMS and Db2 accessed by the API | Executes business logic, interacts with mainframe programs or databases |
| Backend System | Mainframe applications or data sources that provide business logic and data | Processes transactions, returns data to z/OS Connect EE for response formatting |
IBM WebSphere Application Server Interfaces
WAS provides a rich set of interfaces and APIs that support a wide range of application types, integration patterns and administrative tasks. Below is a categorized list of the three key interface categories: WAS APIs, WAS administrative interfaces and WAS integration interfaces.
APIs
Table 3 below lists WAS APIs with a short description of their purpose. They are useful for regular application execution, as well as some reach into application monitoring and management.
Table 3. WAS APIs
| API | Purpose |
| Servlet API | For building web applications using Java Servlets and JSPs |
| JAX-RS API | For creating RESTful web services |
| JAX-WS API | For SOAP-based web services |
| EJB API | For enterprise JavaBeans and business logic components |
| Java Persistence API (JPA) | For object-relational mapping and database access |
| Java Message Service (JMS) | For messaging between components |
| WebSocket API | For real-time, bidirectional communication |
| JSON API | For handling JSON data in web applications |
| Security APIs | For authentication, authorization and SSO |
| JMX API | For monitoring and managing resources via MBeans |
| REST Connector API | For managing WebSphere via RESTful administration endpoints |
Administrative Interfaces
Table 4 below lists five key WAS administrative interfaces. They are useful because they support robust use and implementation of WAS administration activities.
Table 4. WAS Administrative Interfaces
| Interface | Functionality |
| Admin Console (Web GUI) | Web-based interface for managing servers, applications and resources |
| wsadmin (Jython/JACL scripting) | Command-line tool for scripting administrative tasks |
| REST Administration API | RESTful interface for managing WebSphere resources |
| Job Manager | For managing multiple WebSphere cells and automating tasks |
| Deployment Manager (DMGR) | Centralized control for clustered environments |
Integration Interfaces
Table 5 below lists five important WAS interfaces that are focused on integration with different systems. They are useful for integrating with CICS and IMS, as well as other technologies like SOA, Web Services IBM MQ and relational databases.
Table 5. WAS Integration Interfaces
| Interface | Use Case |
| Java Connector Architecture (JCA) | For integrating with enterprise information systems like CICS and IMS |
| Service Component Architecture (SCA) | For composing and deploying SOA-based applications |
| Web Services Gateway | For exposing internal services to external consumers securely |
| MQ Integration | For messaging with IBM MQ |
| Database Connectivity (JDBC) | For connecting to relational databases |
Supported Application Models
Interfaces play a role in supporting the different WAS application models. Why different models? WAS supports different application models to cater to a broad range of enterprise needs and to facilitate modernization efforts. These include:
- Java EE / Jakarta EE – A multitier architecture that defines a set of standard, portable and scalable services for developing and running enterprise applications within managed containers.
- OSGi Applications – Enables developers to create, assemble and deploy highly modular, dynamic and versioned applications by combining Java EE and OSGi technologies.
- Web Applications (WAR) – Packages all web components—such as servlets, JSP files, HTML and other resources into a single deployable archive file for execution within the server’s web container.
- Enterprise Applications (EAR) – Uses an enterprise archive (EAR) file, which is a single compressed archive (a standard ZIP file with an .ear extension). This EAR file packages an entire enterprise application, including its various modules like WAR, EJB JAR and utility JAR files, for coherent and simultaneous deployment.
- Microservices (Liberty Profile) – Supports a lightweight, modular microservices model that leverages open standards like MicroProfile and Jakarta EE to build cloud-native applications with a small footprint and fast startup times.
FTP/SFTP/NFS Protocols
Here’s a concise overview of the FTP, SFTP and NFS protocols—three widely used methods for accessing and transferring files across networks. They are long-standing interfaces.
File Transfer Protocol (FTP)
FTP transfers files between a client and server over a TCP/IP network. It uses port 21 for control and port 20 for data. FTP is not secure by default—data, including passwords, is sent in plain text. FTP is used for uploading/downloading files to/from servers, as well as automating batch file transfers in legacy systems. In z/OS, it is available via the z/OS Communications Server FTP daemon.
SSH File Transfer Protocol (SFTP)
SFTP securely transfers files over an encrypted SSH connection. The protocol uses port 22.
SFTP employs strong encryption for both authentication and data transfer and is used for secure file exchange with external partners. It replaces insecure FTP in compliance-sensitive environments. In z/OS, SFTP is provided through z/OS OpenSSH, part of UNIX System Services.
Network File System (NFS)
NFS allows a system to access files over a network as if they were on local storage. NFS uses port 2049, as well as others for related services. NFS can be secured with Kerberos (NFSv4), whereas earlier versions are less secure. NFS is used for sharing datasets or UNIX files between z/OS and distributed systems. Also used for mounting remote file systems for transparent access. In z/OS there is support for both NFS client and server roles.
2. Security Interfaces
This section discusses three security interfaces including RACF APIs, System Authorization Facility (SAF) and zSecure command interfaces.
RACF APIs
There are over 50 callable services in total, covering identity mapping, auditing, privilege checking and system security management. These APIs are typically invoked from assembler or C programs and are documented in the IBM z/OS Security Server RACF Callable Services manual.
Table 6. Access Checking and Security APIs Examples
| Routine | Usage |
| IRRSKA00 – ck_access | Checks whether a user has the required access authority to a resource like a dataset or general resource class |
| IRRSKF00 – ck_file_owner | Verifies whether the user is the owner of a file or dataset |
| IRRSKI00 – ck_IPC_access | Checks access to Inter-Process Communication (IPC) objects, such as message queues, semaphores or shared memory |
| IRRSKP00 – ck_priv | Determines if the user has a specific privilege (e.g., special RACF attributes like SPECIAL, OPERATIONS or AUDITOR) |
| IRRSKO00 – ck_process_owner | Verifies whether the user is the owner of a process. |
System Authorization Facility
The System Authorization Facility (SAF) APIs in z/OS provide a standardized interface for security-related requests, allowing applications and subsystems to interact with external security managers such as RACF, ACF2 or Top Secret. SAF acts as an intermediary between z/OS components and the security product, ensuring consistent enforcement of authentication, authorization and auditing policies.
Through callable services like RACROUTE, programs can perform operations such as verifying user IDs and passwords, checking resource access permissions and retrieving security attributes. SAF APIs are widely used by system exits, middleware and custom applications to maintain security integrity without hardcoding dependencies on a specific security manager. This abstraction is critical for flexibility and portability in enterprise environments where different security solutions may be deployed. Table 7 contains some examples of the RACROUTE macros and the service that they provide.
Table 7. RACROUTE Services
| Macro | Usage |
| RACROUTE REQUEST=VERIFY | Verifies a user’s identity, user ID and password, and establishes security context |
| RACROUTE REQUEST=AUTH | Checks if a user is authorized to access a specific resource |
| RACROUTE REQUEST=EXTRACT | Retrieves security-related information like user attributes and group membership |
| RACROUTE REQUEST=SIGNON / SIGNOFF | Handles user sign on and sign off processing |
| RACROUTE REQUEST=LIST | Lists resource profiles or user attributes |
| RACROUTE REQUEST=DELETE / ADD / ALTER | Used for administrative updates to RACF profiles |
zSecure Command Interfaces
The zSecure command interfaces provide multiple ways to interact with IBM zSecure for security administration, auditing and compliance tasks on z/OS. At the core is the CARLa Command Language, which is a powerful scripting language that enables advanced queries, reporting and automation of RACF and system security data.
In addition to CARLa, zSecure offers batch interfaces for running commands in JCL, ISPF panels for interactive command execution and integration with RACF commands for direct security administration. Recent zSecure versions also include REST APIs for external automation and dashboard integration, making zSecure highly adaptable for both traditional and DevOps workflows.
3. Monitoring and Automation Interfaces
Monitoring and automation are important for modern systems because the sheer volume of actions needed for “keeping an eye on things” and taking recovery actions is very challenging. The focus of this section is OMEGAMON APIs, NetView command interface, System Automation for z/OS policies and Resource Measurement Facility APIs.
OMEGAMON APIs
IBM Z OMEGAMON does not offer a single set of “main” APIs in the traditional sense, but rather, provides integration points through specific components to external platforms and tools. The primary mechanism for modern integration is the IBM Z OMEGAMON Data Provider.
The IBM Z OMEGAMON Data Provider component makes OMEGAMON metrics and attributes available to applications and analytics platforms by streaming data to open AIOps platforms like IBM Instana, Grafana, Splunk, Kafka and the Elastic Stack. Other
APIs that can be used to integrate with Omegamon are discussed in Table 8 below.
Table 8. APIs That Can Be Used to Integrate with Omegamon
| z/OS Connect Enterprise Edition APIs | OMEGAMON for JVM monitors APIs created with z/OS Connect, allowing performance and response time analysis for mainframe system assets accessed as REST APIs. OMEGAMON examines these API calls and provides detailed reports. |
| SOAP Services | For specific automation tasks and interactions, such as with IBM Z System Automation, OMEGAMON agents provide SOAP-based services for data retrieval and automation triggering. |
| REST Mediation Pack | Older IBM Tivoli OMEGAMON XE products provide APIs through their infrastructure, which can be accessed using the REST Mediation Pack to retrieve performance metric data via a Python client. |
| Data Service APIs via IBM Z Resource Discovery | The IBM Z Resource Discovery Data Service processes and provides discovered z/OS resource data and relationships via modern APIs. |
These APIs allow users to integrate OMEGAMON’s deep performance data into modern IT operations, observability and automation platforms.
NetView Command Interface
The NetView command interface, also called the command facility, is a core component of the IBM Z NetView network management program, providing a text-based method for operators and system administrators to issue commands, receive messages and manage complex network and system resources, including both TCP/IP and SNA environments.
NetView’s importance lies in enabling powerful automation, efficient problem determination and centralized control of an enterprise’s entire network and system operations.
System Automation for z/OS Policies
System Automation for z/OS policies are the core of the automation system, defining how it manages and controls z/OS resources like applications, systems and subsystems. The policy definitions specify the desired state, relationships, and dependencies between resources, enabling the system to automate startup, shutdown and failover processes without requiring human operators to write code.
Resource Measurement Facility (RMF) APIs
The main Resource Measurement Facility (RMF) APIs, used for accessing z/OS performance data for application programming and further analysis, are primarily the Sysplex Data Server API (ERB3XDRS) and the z/OS Data Gatherer API (GRBSMFR).
These APIs allow application programs to access various types of RMF data as summarized in Table 9.
Table 9. RMF APIs and Their Data
| API | What Data it Provides |
| Sysplex Data Server API | Provides access to RMF Monitor II and Monitor III data within a sysplex. |
| z/OS Data Gatherer API | Offers access to any SMF record type and Monitor III data from SMF and Monitor III VSAM data sets. |
In addition to these core programmatic interfaces, RMF provides other ways to access and utilize performance data, which can be considered forms of APIs or interfaces for data extraction:
- RMF Postprocessor: A reporting tool that processes historical SMF records (types 70-78) to generate detailed reports, which can be output in text or XML format for further processing.
- RMF Spreadsheet Reporter/Performance Data Portal: Workstation enhancements that allow RMF data to be converted into a format usable by spreadsheet applications, effectively acting as a bridge for data integration.
- RMF PM and Webportal: Older workstation components that provided graphical interfaces to RMF data via TCP/IP connections, though more modern solutions often use Grafana plugins now.
- IBM RMF for z/OS Grafana Plugin: A modern solution that provides an interface for analyzing and visualizing RMF Monitor III metrics within the Grafana platform, using the Distributed Data Server (DDS) as its data source.
- Distributed Data Server (DDS): A component that provides RMF data to modern analytics platforms like RMF Operational Analytics and the Grafana plugin.
For more detailed technical information on using these interfaces, refer to the z/OS Resource Measurement Facility Programmer’s Guide.
4. Development and DevOps Interfaces
These interfaces are important because they act as the bridge between software development and operational deployment. They make possible speed, reliability and collaboration across the entire lifecycle. The areas of focus in this section are IBM Developer for z/OS (IDz), Visual Studio (VS) Code with Z Open Editor, Zowe Explorer, Git integration via USS or Zowe CLI and interfaces for Jenkins, UrbanCode Deploy and Ansible.
IBM Developer for z/OS
IBM Developer for z/OS (IDz) provides development and DevOps interfaces through its integrated development environment (IDE). IDz’s IDE is based on Eclipse or VS Code. It integrates with source code management tools like Git and IBM Engineering Workflow Management, and supports automated builds and testing using tools such as IBM Dependency Based Build. The toolset simplifies modern DevOps practices by enabling developers to build, test and deploy applications with automated, secure and integrated pipelines.
VS Code With Z Open Editor
IBM Z Open Editor is a VS Code extension designed to facilitate modern mainframe development, bridging the gap between traditional z/OS development and contemporary DevOps practices. It provides a rich editing experience for mainframe languages like COBOL, PL/I, HLASM, REXX and JCL within the familiar VS Code environment.
Zowe Explorer
Zowe Explorer performs as a DevOps interface by connecting modern development tools, like VS Code, to the mainframe, making possible a unified workflow for both traditional and new developers. It allows DevOps teams to manage mainframe assets, like data sets and jobs, from a familiar IDE. You use it to submit jobs and integrate the mainframe into existing automation and continuous integration/continuous delivery (CI/CD) pipelines. This bridging of worlds allows organizations to modernize their mainframe development without sacrificing existing processes and tools.
Git Integration via USS or Zowe CLI
Git integration on the mainframe is achieved by running standard Git commands within the z/OS USS environment or by using the Zowe CLI to interact with mainframe files and data sets from a local machine.
What About Jenkins, UrbanCode Deploy and Ansible?
Jenkins, UrbanCode Deploy and Ansible offer a range of interfaces for developers and DevOps engineers, including web-based user interfaces (UI), command-line interfaces and APIs. The choice of interface often depends on the task, ranging from visual pipeline design to programmatic automation.
Jenkins
Jenkins primarily serves as an orchestration tool for CI/CD pipelines. Table 10 summarizes its uses.
Table 10. Jenkins Interfaces and Their Uses
| Interface | Developer Uses | DevOps Uses |
| Web UI | Viewing build logs, checking pipeline status, manually triggering builds | Initial setup, configuration management, plugin installation and security management |
| Pipeline as Code (Jenkinsfile) | Defining entire CI/CD pipelines within source control using a Groovy-compatible text format, ensuring version control and consistency | Managing and standardizing pipeline definitions across teams and projects, often integrated into Git repositories |
| CLI/API | Automating job creation or configuration, fetching build information or integrating with other tools | Scripting complex administrative tasks and integrating Jenkins into larger automation frameworks |
UrbanCode Deploy (UCD)
UCD, which is now part of IBM DevOps Deploy, is an application release automation (ARA) tool focused on orchestration, governance and compliance for complex deployments. Table 11 summarizes how it is useful.
Table 11. UrbanCode Deploy Interfaces and Their Uses
| Interface | Developer Uses | DevOps Uses |
| Web UI | Viewing application inventories, checking deployment status, requesting environment deployments and using self-service options | Designing multi-tier application deployment processes using a visual drag-and-drop editor, managing environments, scheduling deployments and configuring approvals |
| CLI (udclient)/REST API | Scripting deployment tasks or integrating UCD into existing developer workflows (e.g., triggering deployments from an IDE) | Full programmatic control for advanced automation, creating components, managing configurations and integrating with enterprise-level tools like ServiceNow or Jira |
| Plugins | Interacting with UCD from other CI tools, such as the Jenkins plugin to publish build artifacts directly to UCD | Extending UCD’s capabilities to integrate with a wide ecosystem of tools, from databases to cloud providers |
Ansible
Ansible is primarily an IT automation tool for configuration management, application deployment and infrastructure provisioning, which is sometimes known as “infrastructure as code”. Table 12 captures its uses.
Table 12. Ansible Interfaces and Their Uses
| Interface | Developer Uses | DevOps Uses |
| YAML Playbooks | Defining infrastructure and deployment steps in human-readable YAML files, which are stored in version control software like Git | Creating reusable roles and playbooks for consistent and repeatable provisioning and configuration management across various environments |
| CLI | Running ad-hoc commands, executing playbooks and managing inventories directly from the terminal; this is a primary interface for interaction | Command-line execution of automation tasks, testing playbooks and managing hosts and credentials |
| Ansible Automation Controller (formerly Tower) Web UI | Monitoring job status and viewing execution output in a centralized dashboard | Managing credentials, inventories, job templates and providing Role-Based Access Control (RBAC) |
| API | Integrating Ansible automation into CI/CD pipelines, for example a Jenkins pipeline calling the Automation Controller API to run a specific job template | Programmatic initiation of automation jobs and integration with external systems for event-driven automation |
That’s it!
This has been the last of 24 “z/OS and Friends” articles covering 12 major topic areas. I hope you enjoyed this yearlong journey as much as I did. May this collection of knowledge serve you well in your future mainframe endeavors.
— Joseph Gulla