For years, the green screen has been my home. I know the ISPF shortcuts like the back of my hand. I take pride in my ability to navigate SYSVIEW at lightspeed, hunt down datasets, and trace Assembler macros through split screens. To a mainframe developer, that knowledge is a badge of honor.

But recently, I was handed a challenge: build a new feature that generates detailed dataset information based on JCL SYSIN inputs, and do it using 0% green screen and 100% modern tools. While this breakdown doesn’t cover the entire Software Development Life Cycle (like requirements gathering or final production deployment), it covers the absolute meat of what we do every single day as developers.

Here is the modern toolchain that takes our daily development beyond the standard ISPF panels:

Let’s break down how this workflow actually felt, phase by phase.

1. Analysis & Editing: Eliminating Navigation Friction

🛠️ Tech Stack: Endevor Bridge for Git, Code4z (COBOL/HLASM Language Support, Cobol Control Flow )

The Traditional Workflow: Analyzing code in ISPF involves significant navigation overhead. Simultaneously viewing a MACLIB, the source code, and a reference listing requires constant panel navigation (F3) and logical screen swapping (F9), making it difficult to maintain a comprehensive view of the application logic.

The Modern Workflow:

• Persistent Split Screens: By cloning my repository locally using Endevor Bridge for Git, my workspace is entirely unified. I can split my screen to see my source, MACLIB, and list files all at once. Best of all? No repetitive logins. When I open VS Code the next morning, the elements I was editing are exactly where I left them.
• Intelligent Navigation: The COBOL and HLASM Language Support extensions completely change code traversal. Instead of manual string searches, I just right-click and hit “Peek Definition” or “Peek Reference.” For copybooks, I just hover over the macro and click to open it.
• Taming Legacy Code: When analyzing a 25,000-line COBOL program I’ve never seen before, the Code Outline gives me a structural overview. But for the deep dive, I open the same Control Flow Graph used in debugging. Even without running the code, it generates a visual roadmap of the spaghetti logic, helping me pinpoint exactly where to inject new code without breaking existing flows.

2. Compile & Build: Local Execution & Clean Merges

🛠️ Tech Stack: Team Build, Enterprise Git

The Traditional Workflow: In the traditional Endevor interface, compiling follows a proven, sequential flow: you issue a generate command, wait for execution, and navigate to the list file on a separate screen to review errors. When multiple developers work on the same module, it requires careful, manual coordination to merge changes and ensure no code is overwritten.

The Modern Workflow:

• Frictionless Local Builds: Team Build doesn’t reinvent the wheel — it just brings the process into the local IDE. I can compile and build right in VS Code, and the load module is made available on the mainframe for testing. It makes the existing process seamless.
• Solving the Merge Headache: Because we push our code to an enterprise Git repo, dealing with teammates modifying the same module is no longer painful. Standard Git conflict resolution highlights exactly what changed side-by-side, letting me easily merge code locally before it ever hits Endevor.

3. Testing & Execution: From SYSVIEW Refresh loop to Right-Click Submits

🛠️ Tech Stack: Code4z (Zowe Explorer, Data Editor for Mainframe, JCL Language Support)

The Traditional Workflow: My specific development task required submitting JCL with new SYSIN parameters. The old way meant editing the SYSIN in ISPF, submitting the JCL, backing out, opening SYSVIEW, and frantically refreshing to view the job log output. Then, to verify the actual data changes, I would have to navigate to a different utility like File Master plus.

The Modern Workflow:

• Right-Click Submit: With Zowe Explorer, I just keep my datasets open in the editor. I make my changes to the SYSIN, right-click, and hit “Submit Job.”
• Instant Log Retrieval: Job logs stream instantly to the IDE or download locally via Zowe. Meanwhile, integrated JCL validation catches syntax errors pre-submission, completely eliminating the friction of repetitive mainframe logins.
• Side-by-Side Data Validation: Validating the dataset information was critical. Instead of reverting to a green-screen utility, I used Broadcom’s Data Editor to open target datasets directly in VS Code. This lets me check precise attributes and validate data side-by-side with my job output in one unified view.

4. Debugging & Analysis: The “Cockpit View” of Your Logic

🛠️ Tech Stack: Code4z (Debugger for Mainframe), InterTest / SymDump

The Traditional Workflow: InterTest and SymDump are incredibly powerful, but their 3270 interfaces are bottlenecked by screen real estate. You are forced into constant trade-offs — choosing to view source code, trace data, or monitor a few variables. Because you cannot see the full context at once, tracking complex GO TO or PERFORM logic becomes a fragmented, screen-toggling experience.

The Modern Workflow:

• The “Trifecta” View: This is where the modern interface truly shines. When I launch the Debugger for Mainframe Code4z extension, I don’t just see code. I set up a “Cockpit View” that is impossible in ISPF:
• Left Panel: My Variables (updating in real-time), Call Stack (showing exactly how I got here), and Trace (history of execution).
• Center Panel: The live Source Code with the active execution line highlighted.
• Right Panel: The Control Flow Graph, visually mapping the program’s logic nodes.

Visualizing the Path: As I step through the code line-by-line, the Control Flow Graph on the right animates with me. I can literally watch the path of execution turn green as it flows through the logic nodes.

• Proof of Logic: This isn’t just cool to look at; it is a verification tool. If I expect the code to enter the “High Risk” paragraph but watch the graph divert to “Standard Risk,” I know immediately where the logic broke — without digging through variables to find the cause. It connects the data (variables) with the behavior (graph) instantly.

5. The Reality Check: It Wasn’t All Smooth Sailing

I won’t lie to you — abandoning 11 years of muscle memory is frustrating. The transition wasn’t instantaneous, and I hit several walls that made me want to run back to ISPF.

The Muscle Memory Battle
For the first week, my fingers were my worst enemy. In ISPF, Enter is your "Execute" key. In VS Code, Enter just adds a new line. I can’t tell you how many times I stared at the screen waiting for a job to submit, only to realize I was just staring at a text editor. Losing my F7/F8 scrolling and F3 exit habits took genuine effort to unlearn.

The “Black Box” Anxiety
In Endevor on the mainframe, I know exactly where my code is. Moving to Git was a mental leap. The concept of “staging” and “committing” locally before pushing felt unsafe at first. Is my code actually saved? Did I just overwrite the master branch? Trusting a distributed version control system took time, and I had to force myself to trust the process.

The Setup Curve
ISPF is just there. You log in, and it works. VS Code requires setup. Configuring Zowe profiles, ensuring my certificates were valid, and mapping my local folders to the correct Endevor systems wasn’t a one-click affair. It required me to understand the “plumbing” of how my PC talks to the mainframe — something ISPF had always hidden from me.

The Bottom Line

Taking the challenge to go 100% modern for this core part of my daily work was an eye-opener. Moving from ISPF to a modern, Git-driven, VS Code-based stack isn’t about replacing the mainframe — it’s about replacing the friction. By leveraging Endevor Bridge for Git, Zowe, and Broadcom’s Code4z extensions, I get to keep the reliability and power of z/OS while finally adopting a workflow that lets me focus entirely on the code, rather than the environment.

If you are a mainframe developer holding onto your green screen, take it from me. Jump in.

My Journey From ISPF to VS Code and Git With Code4z was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s expand on what is and how are PL/I preprocessor statements and usage of these preprocessors in VS Code extension for PL/I Language.

What is a PL/I Preprocessor?

Before answering that question, let’s understand what a preprocessor in computer science is. A preprocessor is a program (automated editor or text manipulator tool) that processes (precomputes or modifies) source code (its input data) before the actual program compilation begins. In other words, its processed output data will be used as an input data to another program [2].

The PL/I preprocessor is the preprocessor for PL/I programming language, that prepares the PL/I source code for the compiler.

The Role and Challenges of PL/I Preprocessors

The PL/I preprocessor is known as a powerful PL/I compile-time facility tool that operates as a “compiler before the compiler.” It works by scanning source code before the main compilation stage and identifies special commands prefixed with a percentage sign (%), such as %INCLUDE, %DCL, and etc. PL/I preprocessor supports complex logic, variable manipulation, and string processing to generate optimized or customized code (favor of custom syntax instead of the ones written on the stone).

But PL/I preprocessors bring key challenges in legacy environments like: Invisible syntax errors (standard editors fail to recognize macro syntax), no code completion support, code obscurity (e.g. without modern tools you have to expand macro), and monolithic complexity.

How VS Code Makes Developer Work Easier

Modern extensions such as code4z — PL/I Language extension can help to solve these challenges by integrating preprocessor logic inside the IDE and offers several technical advantages that bridge the gap between legacy mainframe development and modern software engineering.

Here are the key benefits of PL/I Preprocessors support in VS Code: Real time syntax accuracy, persistent language intelligence (code completion, go-to definition, hover-over etc.), integrated error handling (e.g. can highlight the skipped code with low opacity) and semantic awareness (e.g. some variables and procedures that are only available after the preprocessor has run)

Key Preprocessor Facilities

PL/I processors provide a wide range of preprocessor facilities for developing, optimizing, and maintaining mission-critical applications. These processors are designed for versatile, high-performance computing, supporting scientific, engineering, and commercial data processing [3].

Preprocessor Statements

The PL/I preprocessor uses a set of specific preprocessor statements to manipulate source text, manage conditional compilation, flow control, and automate code generation. Preprocessor statements are executed when encountered for:

Declarations and activation: %DECLARE (or %DCL), %ACTIVATE, etc.

Control flow and conditional logic: %IF…%THEN…%ELSE, %DO, %END, %SELECT etc.

Code generation and Inclusion: %ANSWER, %INCLUDE, %INSCAN, %XINCLUDE, %XINSCAN etc.

Utilities: %NOTE, %NULL

Integrated Include Preprocessor: Allows you to incorporate external source files into your programs by using ‘via ++INCLUDE or -INC’ directives beyond the standard include directive.

Preprocessor procedures (also called as Macros)

You can use preprocessor statements and groups inside preprocessor procedures to perform many kinds of different operations, like below:

Validation: Use %IF inside the procedure to check if arguments are valid and provide a diagnostic message using a %NOTE if they aren’t.

Complex Formatting: Use built-in functions like INDEX, SUBSTR, and TRANSLATE to play with input data before it becomes coded.

State Management: Procedures can update global %DCL variables to keep track of how many times a particular code block has been generated.

Providing results: To pass results pack to preprocessor scan use either ANSWER or RETURN statements.

Macro preprocessor options

To enable macro preprocessors, you can either use PP(MACRO) compile-time option in the program after %PROCESS directive or define it in the configuration file for global usage.

You can use macro preprocessors for below use-cases:

Data and Syntax control: using NAMEPREFIX (character) and FIXED(option) to determine default base for preprocessor variables and use

Source code handling and transformation: Use CASE(UPPER|ASIS) option whether the preprocessor converts your input source text to uppercase before processing it. The RESCAN (UPPER | ASIS) option controls how the preprocessor behaves after it has already performed a text replacement.

Use DEPRECATE (ERROR | WARN) to flag macro procedures that are intended to be phased out, issuing either a warning or an error.

Use INCONLY option to only handle %INCLUDE and %XINCLUDE and ignore other macro logic.

See below code animation for some preprocessor examples or just try it on your own PL/I code:

In case you have not installed or used the extension, please try the guidance here.

Summary

PL/I preprocessors provide significant advantages in mainframe development by enabling code automation, enhancing maintainability, and improving the efficiency of the compilation process. They allow developers to manipulate source code before it is passed to the compiler using specialized preprocessors which we mentioned above in detail.

In coming releases extension will extend its support to PL/I specialized integrated preprocessors like CICS and DB2, they will be processed inside a block EXEC CICS and EXEC SQL respectively and translates (CICS and SQL) statements into PL/I calls.

For further information, you may contact us on Slack: che4z.slack.com

References

[1] https://azat-satklichov.medium.com/pl-i-the-newest-mainframe-language-code4z-extension-68e27a7ab420

[2] https://en.wikipedia.org/wiki/PL/I_preprocessor

[3] https://www.ibm.com/docs/en/epfz/5.3.0?topic=reference-preprocessor-facilities

[4] https://www.ibm.com/docs/en/epfz/5.3.0?topic=guide-pdf-version

Code4z VS Code PL/I Language Extension Preprocessor Support was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Large Language Models (LLMs) are incredibly powerful, yet they are traditionally limited by a knowledge cutoff and a lack of access to your private, evolving data. When discussing a complex Endevor environment, the difference between a standard LLM interaction and one powered by a Model Context Protocol (MCP) server is the difference between general speculation and actionable intelligence.

Without an MCP server the LLM operates in isolation. It relies solely on its static training data and local context, lacking visibility and automation within your specific Endevor inventory structure, element history, metadata, or processor configurations.

When staring at 10,000 lines of COBOL in VS Code, even the latest and greatest LLM cannot help the new mainframe developer assigned to fix the latest bug in the program. Outside of the code within the element, the LLM is clueless about the element’s purpose in the larger context of an inventory.

🚩 It does not know how an element is used.

🚩 It does not know about change history metadata.

🚩 It definitely does not know how an element is built.

Does the LLM work with Explorer for Endevor?

Modern Mainframe developers rely on the Explorer for Endevor (E4E) Visual Studio Code extension from Code4z to navigate familiar codebases with precision. However, the extension was never designed to interface with an LLM. This disconnect makes it difficult to feed Endevor information into the model’s context. Additionally, the LLM cannot directly use E4E for resource retrieval, meaning the user always has to be in the loop to relay this context. This creates an efficiency bottleneck around information access.

The Challenges

⚠️ Contextual Blindness: The model cannot read your specific stages, systems, or subsystems, leading to generic advice that may not apply to your environment.

⚠️ Manual Data Entry: You are forced to copy-paste logs, SCL (Software Control Language) snippets, print listings, or inventory reports into the chat, which is time consuming and risks hitting context window limits.

⚠️ Inaccuracy & Hallucination: Lacking real-time data, the LLM may guess at element locations or dependency impacts, potentially leading to errors in your change management process.

Introducing Code4z Assistant

We are excited to introduce Code4z Assistant, a read-only bridge that connects your LLM of choice directly to your Endevor inventory.

Code4z Assistant is a VS Code extension containing an MCP server compatible with any local MCP client that supports MCP tools and streamable HTTP. It transforms the LLM from a general assistant into a context-aware subject matter expert that can query your mainframe data on demand. Think of Code4z Assistant as a toolbox containing special tools for interacting with Endevor Web Services.

The Benefits:

✅ Real-Time Retrieval: The LLM can proactively retrieve the status of a package, an environment mapping, or the history of an element using standardized tools.

✅ Reduced Overhead: Instead of flooding the chat with data or not having enough of it, the MCP server provides only the specific resources needed for the current task. Keeping the conversation and the context window size efficient.

✅ Precision Tooling: The LLM can troubleshoot build failures and inspect packages with direct access to the actual error logs and environment configurations.

Upgrade Your Daily Flow

Understand code and analyze impact

Mainframe Applications are a web of dependencies. Before, finding the impact of a change involved manual searches. Now the LLM uses the get element usage or get element dependencies tools to traverse up and down the dependency tree. As a result, the developer gets a top-level map of the environment in one window:

Track and coordinate changes

Mainframe code isn’t just code; it’s a history of business decisions. By exposing get element changes, the LLM can explain why and how a piece of code exists:

Understand Endevor Builds

Processors and component lists shouldn’t be a black box. By exposing get processor group, the LLM is enabled to retrieve a list of processor groups for a given element. If you are unsure of how a given element is built, you can ask the LLM to summarize the build process. It’s like having a DevOps engineer sitting right next to you:

How it Works

We designed this with the modern developer experience in mind. No complex green screen navigation is required.

1. Install: Developers install the Code4z Assistant extension in their VS Code environment alongside Code4z , including Explorer for Endevor, and any other preferred extensions.
2. Configure & Connect via EWS: Developers connect to Endevor via existing Endevor Web Services (EWS) host URLs and credentials (or a locally provisioned Zowe profile).
3. The Secure Bridge: The MCP server runs on a local port as a subprocess of the Code4z Assistant VS Code extension, allowing any locally compatible MCP client (like Copilot, Cline, or local LLM interfaces) to fetch context directly without ever having to share EWS credentials with the LLM.

Ready to give your LLM a Mainframe education?

Connect with the Code4z Assistant team to access our pre-release MCP Server available on the DevX and DevOps Validation Community:

• Ekaterina Tumanova — ekaterina.tumanova@broadcom.com
• Petr Galik — petr.galik@broadcom.com

Sliding Mainframe into the Context Window: Connect your LLM with Endevor using MCP was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mainframe modernization is not only about creating new applications to access mainframe applications from open source solutions like Visual Studio Code (VSC), Eclipse CHE, Zowe CLI, etc., but also involves adapting existing legacy applications to connect to external/internal web services. One modernization effort involves integrating Endevor with ServiceNow. This integration can serve two similar purposes: validating an Endevor CCID or verifying the name and readiness of an Endevor package. This blog focuses on the ServiceNow validation for Endevor packages. The solution goes beyond simply checking for the existence of the ServiceNow entry; it mandates that the entry’s status must be in the correct state.

While various software solutions exist for this type of integration — such as Python, GoLang, and Java — this document focuses on a different approach. We leverage the z/OS Client Web Enablement Toolkit. This toolkit is built directly into the base of the z/OS operating system, offering a lightweight solution. Its key value is enabling traditional, native z/OS applications to more easily engage in the client/server space by providing built-in features for this connectivity:

• A z/OS HTTP/HTTPS protocol enabler which uses interfaces similar to other industry-standard APIs.
• A z/OS JSON parser that can be used to parse JSON text that comes from any source and create new JSON text or add to existing JSON text.

Almost all environments on z/OS can take advantage of these new services. Programs can use these APIs in the programming language of their choice. You can use REXX, C/C++, COBOL, PL/I, and Assembler languages.

In this implementation, the programming language selected for building the integration between the z/OS LPAR and ServiceNow instance was REXX, although the Endevor User Exit 7 was written in COBOL.

✅ z/OS HTTP/HTTPS protocol enabler

The HTTP/HTTPS enabler portion of the toolkit allows Endevor to:

• Make simple API calls to connect to the ServiceNow server
• Build an HTTP request, send it to the ServiceNow server, and receive a response.

Endevor uses the toolkit to execute REST API calls against a ServiceNow instance by following this scheme:

1️⃣ Initialize a connection (HWTHINIT) to get the work area ready for the toolkit to process the connection to ServiceNow.

2️⃣ Set the necessary connection options (HWTHSET). In this step, the URI of the ServiceNow web server, SSL options, cookie processing behavior, and other options are set, one option at a time.

3️⃣ Connect to the ServiceNow instance server (HWTHCONN).

4️⃣Initialize a request (also HWTHINIT) to get another work area necessary for the toolkit to process the request.

5️⃣Set the necessary HTTP request options (also HWTHSET):

🕐 HTTP request headers which need to be sent to the ServiceNow server.

🕑 Request body.

🕒 Application code receiving control to process the data that is returned from the snow web server.

Setting one option at a time.

6️⃣Send the request (HWTHRQST) to join the request to a particular connection and send it over that connection. The responses are sent back Endevor user exit routines (exits).

7️⃣ Clean up the execution environment to release work area storage, disconnect from Snow web server, and end the connection.

✅z/OS JSON parser

z/OS JSON parser is used to process the JSON text file sent from the ServiceNow web server to the Endevor user exit routines, following this scheme:

1️⃣ Start the JSON parser initialize service (HWTJINIT) to create a parsing instance.

2️⃣ Call the JSON Parse service (HWTJPARS) to have the parser validate the syntax of the text stream and create an internal representation of the JSON text data. Once the data is parsed, it allows all subsequent services to run faster because the data is usually instantly available.

3️⃣ Get the data that is needed using the JSON Search service (HWTJSRCH) to find a specific key in the data (a name in a JSON name/value pair). If that key is found, the value can be retrieved by using one of the parsers “get” services. You can also scope search to a particular JSON object if desired.

4️⃣ When the process is finished, the parser instance (HWTJTERM) is used to free the storage that is being used by the parser.

You can find more information about the toolkit in z/OS MVS Programming: Callable Services for High-Level Languages.

✅Endevor — ServiceNow Integration Overview

1️⃣ Synchronous and Real Time Interface from Mainframe to ServiceNow Instance.

2️⃣ Use SSL communication — Certificates in SAF Keyring

3️⃣ Secure access using authorizations tokens from Endevor to ServiceNow API — OAuth2

4️⃣ Basic Authentication is also provided.

5️⃣ Trace Facility.

✅ ServiceNow Change Request State Values

The change request process has many states, and each of them is of vital importance to the success of the process and the quality of the service provided. The different states are represented in the following diagram:

The above states are configurable and are included in a ServiceNow table with their corresponding attributes

✅ Integration Architecture Overview

OAuth 2.0 is an authorization standard designed to provide third-party applications with a secure method for obtaining limited access to a user’s data on a separate service without requiring the user to disclose their password. The mechanism operates through the issuance of an “access token,” which the user’s browser subsequently utilizes to retrieve specific resources, such as ServiceNow entry details. This protocol is the established standard for authorization across a multitude of widely used applications and services.

The OAuth2 client, Endevor Package Exit 7 — ServiceNow Driver in this example, is the application that requires access to protected resources, such as a change request details or data. Before the client can access these resources, it must first get an access token, which serves as proof of authorization to access the requested resources. The client must first be authorized by the resource owner (ServiceNow Instance) and must hold a valid access token in order to access protected resources. The ServiceNow API server hosting the protected resources will validate the access token to ensure that the client is authorized to access the requested resources and will return a JSON file containing the information corresponding to the issued request.

Creating an OAuth2 client in ServiceNow is a necessary step to enable Endevor Driver to use OAuth2 flows. Before using OAuth, the application must be registered with the service you plan to integrate with (ServiceNow Instance). This is done through a registration form in the developer or API portion of the service’s website, where the application name is provided.

After the application is registered with the service, a client ID is received from the authorization server and optionally a client secret. These are unique identifiers that allow the authorization server to identify your application and allow it to access protected resources. The client ID is considered public information and can be included in any language source code or used to build login URLs. The client secret, however, must be kept confidential and is used to authenticate the client to the authorization server.

✅ Endevor Package Lifecycle Steps

The Endevor Package Lifecycle steps integrated with the ServiceNow Change Request module are:

Below you will find a detailed description of each of the steps in the lifecycle of an Endevor package and the integration performed with the ServiceNow Change Request module:

CThis step automatically creates an Endevor Package ID using the change request number returned by the ServiceNow Instance and following the nomenclature described below:

Endevor Packages ID can be created in three different ways:

1️⃣From scratch, using the new Change Request number provided by ServiceNow,
2️⃣Next in sequence package, using a previously created Package ID associated to a ServiceNow change request or
3️⃣Absolute package ID following the nomenclature described above. A Change Request number already active in ServiceNow is mandatory.

Below you will see an explanation of each type of Package Creation:

You only need to provide the suffix ‘SNCHG#’ in the Package ID field and select option 2 from the Package Panel Menu, the interface will POST a request to the ServiceNow Instance and the Change Request returned will be used in the new Package ID constructed:

Once the Package is populated with all the elements needed, it is finally created (Package Constructed):

and a WORK NOTE is posted to the ServiceNow Change Request number about this fact:

In this implementation, a total of 776 different packages ID could be created for the same ServiceNow Change Request. The last 2 characters of the packet ID define the sequence number and range from ‘AA’ to ‘ZZ’ (676 values) and ‘00’ to ‘99’ (100 values).
In order to create a new package ID for an already created Change Request, the suffix containing the Change Request number should be specified in the Package Panel:

When the package is finally constructed, a Work Note is added to the Change Request in ServiceNow:

We can create a new Package ID for an already created ServiceNow change request and assign it the sequence number of your choice. The interface validates that the Change Request is already active and has the expected state:

A WORK NOTE is also added when the package is created this way:

AAn Endevor Package ID created for a ServiceNow Change request can only be CAST if the Change Request State is APPROVED

Executing the CAST Step using ISPF Panel, Batch Package or any IDE of your preference:

So, let’s approve the Change request using the ServiceNow UI:

FThe ServiceNow change request linked to a Package ID should be in APPROVED state so that package approvers can approve/deny it, like in the previous step of the Package Lifecycle (CAST).

ITo execute an Endevor package linked to a ServiceNow CR, two conditions must be met:

🕐 ServiceNow change request in “IMPLEMENT” state and
🕑Endevor package execution date/time within the execution window defined at the change request field “Planned Start Date/Planned End Date”

Let’s execute an Endevor package linked to a ServiceNow change request:

The Endevor package cannot be executed because ServiceNow change request is not in “IMPLEMENT” state. Let’s connect to ServiceNow UI and promote the CR to the next phase within the CR lifecycle:

Once the CR has been promoted, let’s try the Endevor Package execution step once again:

A new error message is issue because the Package execution Date/Time is not within the ServiceNow change request execution window, actually this window has not been set yet.

Let’s modify the Schedule Tab in the Change Request:

and try the Package execution step once again:

TTo Ship an Endevor package linked to a ServiceNow CR , the same two conditions like the Execute Package Step must be met:

🕐 ServiceNow change request in “IMPLEMENT” state
🕑Endevor package execution date/time within the execution window defined at the change request field “Planned Start Date/Planned End Date”

The validation process is the same that was used for the Package execution step, but this time using the SHIP step available at the ISPF Panel or the Batch Package Facility.
Exception Management is available for every error message returned by the communication process or by the condidtions that are not met during the execution of every package step.

In the next blog Endevor Element CCID validation against ServiceNow using OAuth 2.0, I will show you how to validate Endevor Element Actions Change Control IDentifiers (CCID) against ServiceNow Incident Management Module and act according to the state of the incident.

⚠️Additional Resources.

The source code programs are available on github at https://github.com/BroadcomMFD/broadcom-product-scripts.

Integrating Endevor Package Lifecycle Steps with ServiceNow Change Request Module using OAuth 2.0 was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s get one thing straight: I did not achieve a 100% successful transformation in my last role.

But I did learn from my mistakes. Over the course of my efforts, I came to realize transformation is possible, once you have the right mindset.

Read on to see how I made mistakes, learned, and ultimately realized how to best approach large-scale transformation projects successfully.

My mission for five years as a DevOps Transformation Engineer was to modernize our zDevOps practices. This meant moving our teams from a traditional, in-house SCM to modern GitLab CI/CD pipelines.

And I failed, repeatedly.

I failed with some of our most brilliant developers. These were the “hall of fame” rockstars with 30 years of muscle memory on a 3270 “green screen” terminal. These developers were so fast and so efficient that they could run circles around a new hire using a modern IDE.

And I walked in and asked them to trade that mastery for VS Code.

This was like asking a grandmaster concert pianist to start over and learn the guitar. I learned very quickly that DevOps transformation is not a science. It’s an art.

The tools, like GitLab, VS Code, and SonarCube, aren’t the solution. They’re just the paint. The real work is human. It’s messy. And it requires you to drop the “engineer” mindset and become part-therapist, part-salesman, and full-time relationship builder.

My First Mistake: Leading with the “Solution”

Like any good engineer, I started by showing my “customers” the solution. “Look at this new tech! It’s better!”

The resistance was immediate and justified.

• “This is slowing me down.”
• “My current tools work perfectly fine.”
• “This feels like a waste of my time.”

They were right. My new “better” way was making their productive lives worse. I was asking them to “slow down to go faster later,” but I wasn’t giving them a compelling reason to trust me. I was trying to sell the destination (a modern pipeline) without respecting the cost of the journey (unlearning decades of mastery).

I had to throw the playbook out. I realized you can’t “convince” anyone. You have to continuously adapt, get creative, and find a different angle for every single team.

The “Aha!” Moment: Stop Pushing, Start Listening

My job wasn’t to “roll out tools.” My job was to build relationships.

My entire strategy shifted. I stopped trying to convert the “rockstars,” the ones who were perfectly happy and efficient. That was a losing battle.

Instead, I went looking for a different archetype: the “Eager and Willing Champion.”

In every area, in every team, there’s always one person who is curious, open to new ideas, or just loves new tech. They might not be the team lead or the “rockstar,” but they are respected.

My entire focus shifted to finding and empowering that one person.

They became my new customer. My goal was to make them successful. The single most important part of my job became:

1. Find that one “champion” on a team.
2. Build a real relationship with them. Listen to their specific problems.
3. Give them a “superpower” that made their life immediately better.

The “Superpower” Tactic

This is where the tech comes back in.

For many of these new champions, the “superpower” I could offer was Copilot Assist in VS Code.

This wasn’t about “migrating to Git.” This was about, “Hey, I know you’re working on that REXX script. Check this out.”

The moment they saw Copilot analyze an API Swagger doc and generate code, or help them build a complex DB2 query in seconds, their eyes lit up.

That “wow” moment did what months of my “transformation” PowerPoints couldn’t.

• It gave them an immediate, almost magical boost for a specific, annoying task.
• It gave them a reason to voluntarily open VS Code.
• It made them the “smart” one who could show their team a cool new trick.

I wasn’t the “DevOps guy” forcing a change anymore. I was the “helper” who gave them a new toy.

That champion, armed with their new superpower, would then go to their team meetings and naturally influence their peers. A recommendation from a trusted teammate is a thousand times more effective than a mandate from me.

What “Success” Really Looks Like

This was a slow, patient, and deeply human process. It was about finding one champion, then another, and slowly building a coalition of the willing.

Some of the “rockstars” still hadn’t budged by the time I left that role. And that’s okay. The organization kept running.

Here is what did happen:

• We built momentum. Adoption of modern tools like VS Code began to spread organically, team by team.
• We improved collaboration. For the teams that did migrate, their ability to collaborate with offshore resources and streamline code reviews with merge requests improved dramatically.
• We became “talent-ready.” We built a modern platform that could attract new developers who expect these tools, while also proving that the mainframe itself (running Python on Z, integrating with Zowe) is a powerful, modern environment.

The biggest lesson I learned is that technology is easy. People are hard.

The “art” of transformation isn’t about having the best tools. It’s about having the most empathy. It’s about respecting the mastery of the people you’re trying to “help,” and having the patience to build one relationship at a time.

And ultimately, I learned that a “full migration” mandate might be the wrong goal entirely. Our organization wanted one toolchain, but a hybrid approach, which was not considered, is often the smarter one.

The real goal shouldn’t be 100% conversion; it should be 100% productivity. And that means giving each engineer the best tool for their specific job, even if that means supporting two ways of working.

The Art of Mainframe Modernization: What I Learned Selling “Change” to Green Screen Rockstars was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Brought to you by Broadcom Mainframe Software

Tuesday, December 2nd
11:00 a.m. ET / 10:00 a.m. CT

REGISTER NOW

How can AI enhance the Z developer experience without disrupting existing processes or, more importantly, compromising the codebase?

With AI revolutionizing the developer experience, GitHub Copilot has emerged as the dominant AI coding assistant, especially among large enterprises. However, the stakes for mainframe teams working with mission-critical business applications are high, so adoption risk should be carefully considered.

Key Takeaways:

• This session will explore how to utilize Copilot as an integral part of modern Code4z developer workflows by focusing on high-value, low-risk use cases and policy-compliant deployment.
• We’ll explain how to take advantage of the MCP protocol to access source code in tools like Endevor safely and securely.

Can’t attend the live event?

Register to receive the recorded version

Webinar: AI Code Assistants for IBM Z was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Tool for Understanding Large Programs

Basic COBOL language features like syntax highlighting, navigation between variable definitions and usages, and other essential tools come from the COBOL Language Support Code4z extension, which is automatically installed along with COBOL Control Flow. Those features are helpful but fall short when you need to understand the structure of a large program or the dependencies between its procedures, especially when there are many PERFORM and GO TO statements.

For the COBOL Control Flow extension to understand a COBOL program, it must parse the source and all of its dependencies, understand the relationships and present this to the developer. This takes time, especially with long programs. In version 1.2.1, analysis and graph generation have become at least 4 times faster. For example, the processing time for a complex program with 3,700 lines of code and numerous PERFORM and GO TO statements was improved from 40 seconds to just 12 seconds, with the graph analysis completed in 1 second. Nice.

Also there is a new UI — new icons and buttons, as well as a completely redesigned rendering engine that can now handle very large graphs efficiently. The new graph orientation is vertical, making it easier to follow the program logic from top to bottom and left to right. All of this helps you stay focused on the flow.

You still have access to all the familiar features, including Code-to-Node and Node-to-Code navigation, as illustrated in the image below (Fig. 1). Considering that nodes are now arranged along horizontal levels for improved readability, collapsing and expanding child nodes now behave in a more consistent and intuitive way (Fig. 2)

For large graphs where a simple screenshot isn’t sufficient, you can now export the entire graph as an image file. This allows you to view it on a larger screen or easily share it with colleagues via email

If you want to analyze the graph using external tools, you can export it in DOT format, a standard graph description language compatible with many visualization and analysis tools (Fig. 3).

Improved Precision

The visuals must be clear and precise. The new approach in V1.2.1 significantly improves this. The extension now correctly processes ALTER statements that redirect GO TO targets. It also includes support for CICS and SQL statements that impact the control flow, and we have improved support for PERFORM … UNTIL and GO TO with multiple targets.

Of course, there are many extensions that support a wide range of COBOL statements. However, the execution context of these statements also plays a crucial role and can significantly impact the resulting control flow graph.

For example, let’s examine the following fragment of a COBOL program.

CALC1.
  ALTER PAR2 TO PROCEED TO PAR_NEW.
  PERFORM PAR1.

PAR1.
 GO TO PAR2.

PAR2.
 STOP RUN.

PAR_NEW.
  ...

The COBOL Control Flow engine analyzes the control flow of a program by taking into account the context of execution. For example, when an ALTER statement is executed, it dynamically modifies the destination of a GO TO statement. If you execute ALTER PAR2 TO PROCEED TO PAR_NEW, and then execute GO TO PAR2, the control will be redirected to PAR_NEW. If the execution context is not properly maintained, the analysis may incorrectly terminate at a STOP RUN statement that is not actually reachable. As a result, the generated control flow graph will display only a few nodes.

By preserving and tracking the execution context, the CCF engine can build control flow graphs that more accurately reflect the actual runtime behavior of the program, rather than just static code structure. This improved analysis is essential for identifying hidden bugs and understanding the true procedure dependencies in complex COBOL applications.

The engine also detects and processes statements that reset or override previous redirections, such as another ALTER or conditional logic that changes control paths. In such cases, it updates the execution context accordingly to maintain an accurate flow.

This analysis is not limited to ALTER statements. The CCF engine also handles other constructs that affect control flow depending on context — such as a PERFORM section that contains a GO TO statement with a target inside the section. The behavior of GO TO inside a performed section can differ significantly from a direct GO TO to a section.

Furthermore, control-altering statements inside conditional blocks (e.g., within IF conditions) are also tracked by the engine.

Ultimately, the CCF engine provides a realistic, context-aware view of your COBOL program’s execution. Instead of just listing procedures and their static dependencies, it reconstructs the true dynamic control flow, helping developers better understand, maintain, and debug large legacy codebases.

These improvements make it easier to understand large COBOL programs and spot potential issues.

Conclusion

With COBOL Language Support and the newly improved COBOL Control Flow extension, you can now understand and navigate large COBOL programs faster and more accurately than ever. If you haven’t tried the new version yet, now’s the time!

Useful links

Code4z Foundation pack with more Code4z extensions

More info about COBOL LS:

​​VS Code Language Server Extension for COBOL Preprocessors

LSP Magic — Mainframe Language Support in Modern IDEs

New Code4z COBOL Control Flow 1.2.1: Better and Faster was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Code4z now offers support for Programming Language One (PL/I) applications. This extension has been added to the Code4z Foundation pack for VS Code, which includes COBOL, HLASM, REXX, and JCL. Edit capabilities that Code4z users expect in a modern edit environment are now available for PL/I application developers.

What is PL/I

PL/I or PL/I (Programming Language One) is a high-level programming language developed primarily for scientific, engineering, and business applications. It was unique in that it could handle both scientific computation (like FORTRAN) and business data processing (like COBOL). PL/I has a number of capabilities unique in its time, which are important but challenging for adding intelligence to an edit experience. Some of the PL/I capabilities that are challenging to support were:

Flexible Data Types

• Fixed-point and floating-point numbers
• Decimal arithmetic (important for finance)
• Character strings of variable length
• Pointers and structures (like C later would)
• Unions (similar to C’s union)

Compile-Time Capabilities

PL/I supports compile-time procedures, enabling conditional compilation and code generation based on compile-time logic — another rarity at the time.

No Reserved Keywords

PL/I had no reserved words — you could name a variable IF or THEN, which could lead to confusing but technically valid code.

Modern Tooling for Mainframe Languages

Big steps towards modern tooling and interfaces support exist for mainframe systems built on COBOL, HLASM, REXX, and JCL under the Broadcom all-in-one Code4z Foundation extension pack, and now for PL/I. PL/I is well known in both the scientific and financial areas for its versatility and reliability. It is very efficient for complex, large-scale applications.

This constitutes a sizable number of business-critical applications needing to be maintained and supported. So now, leveraging a modern development environment like Code4z is available to PL/I program developers.

Building a Language Application

Similar to other smart editor modern language extensions, PL/I is using the Language Server Protocol (LSP). LSP is an open-standard protocol aimed to be used between development tools and language servers, therefore allowing flexibility of IDE’s from a modern IDE point of view, LSP is a consistent way to bring the magic of modern editing capabilities. It is an architecture, which brings all the language-smartness features like go to definition, code completion, highlighting syntax or semantic errors, and more others related to your code.

LSP Architecture offers the flexibility of choosing any technology combination to implement the client and language-server independently. For example, we have used this LSP Architecture for our all-in-one ‘code4z’ solution to implement language servers, e.g. “COBOL Language Support” using multiple technologies (JAVA, ANTLR, VS Code, Typescript, LSP, etc.).

PL/I Language Extension

More specifically, the PL/I language support was implemented using the LSP specification vscode-languageclient-*, vscode-languageserver-* libraries. As a result, we provided a PL/I coding assistance tool — a VS Code extension, which brings a similar experience when coding with other languages like JAVA, Python, or Typescript in your modern IDE. It supports and provides rich features such as parsing & validation, syntax highlighting, code completion, and cross-reference linking for PL/I code.

The advantage of this above architecture is, it is based on one language (only Typescript) on all used technology stack here, and this removes any external dependencies like installing JAVA or Python. Simply, there are no client or server-side prerequisites for PL/I Language Support. Moreover, it is based on a custom PliParser based on Chevrotain language recognizer tool, which gives us a more performant (high speed) PL/I syntax analyzer, especially handy when analyzing big programs.

PL/I language support extension is free to install and intended to be used by application developers and by any other users who work with z/OS applications built on PL/I language.

Installing VS Code Extension for PL/I Language Support

In the VS Code extension tab, search ‘pl/1’ or ‘pl/i’ and find the extension to install. No dependency (additional installation like JAVA or Python) is needed to be able to use the extension.

PL/I Language Support provides language awareness features on file extensions .pli, .pl1 and .inc. Create a new or open an existing PL/I file (e.g., FILE.pli), and start using the following language-aware features during coding.

What are the features supported by the PL/I extension?

PL/I Language Support enhances the PL/I programming experience on your IDE and provides below features.

• Syntax and Semantic Analysis — Syntax check analyzes the program based on PL/I program grammar and suggests a fix, and the semantic check highlights incorrect names of variables, procedures and copybooks.
• Code completion / Autocomplete — speeds up the coding process by intuitively suggesting the most likely variables, keywords and building blocks of the PL/I language.
• Code Snippets — enables inserting the reusable blocks of code or text into a program, which helps to speed up writing the code or use as a common practice shared among the team
• Go To References — identifies all occurrences of variables in the code.
• Go To Definition — via right clicking on any variable, you can reveal a definition of the element.
• Playground Support — PL/I Web Playground provides (via GitHub pages) online editor to try to test any code easily and quickly. It also allows sharing the content remotely and instantly with your colleagues.
• Outline and Breadcrumbs support — enables a structural view of program elements and allows easy navigation between them.
• Smart Tab — enables tuning your editor columns to follow the PL/I coding experiences
• Syntax Highlight — enables highlighting for PL/I code
• Syntax Coloring — enables identifying and distinguishing the keywords, variables, procedures and language built-ins.
• Compiler Options — provides inserting PL/I compiler options to tune the program according to your needs. It offers suggestions and validations among the chosen variants.
• PL/I preprocessor — interpret PL/I code to form source file inclusion, conditional compilation, and macro expansion
• Include support — allows inserting copybooks or useful code blocks into your PL/I program. Therefore, you can keep your copybooks independently and share easily across the team.

Let’s try ‘Go To Definition’ support within the included file by the name of an include file and the variable defined in the copybook. Also, you can easily see the preprocessor %DEACTIVATE working correctly, and it removes the variable PAYROLL declaration which is why you have the warning at the end.

Another handy feature is using configuration files to define compiler options for compiler directives or macros. So, you do not need to define it in source code; it brings the same experience as you define such options in JCL, which is very useful in production code.

Playground Support

Imagine you have a great idea and want to test it directly, and want to share it with your team instantly, but you cannot do it because you need to install the application first and set up an environment locally, which is impossible during a real-time meeting.

PL/I Playground enables creating interactive, editable coding environments on the web, with live updating previews. You can use Playground Elements to:

• Do a PoC on code examples quickly and easily without installing anything
• Share the content remotely with your colleagues or customers
• Build full-featured coding samples
• Prepare workshop environments and interactive tutorials with examples
• Build full-featured coding sandboxes

Summary

This PL/I extension provides a modern experience to users who work with z/OS systems written in the PL/I language.

For further questions, contact us on Slack: che4z.slack.com

References

[1] https://medium.com/modern-mainframe/lsp-magic-mainframe-language-support-in-modern-ides-4ea3d81259b3

[2] https://medium.com/modern-mainframe/dap-magic-modern-debugging-experience-for-mainframe-software-deecb40df4c8

[3] https://langserver.org/

[4] https://medium.com/codex/antlr-magic-developing-mainframe-language-applications-using-language-recognizer-5262726e1e93

[5] https://itexus.com/pl-i-programming-language-one-overview-and-applications/

PL/I — The Newest Mainframe Language Code4z Extension was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

CICS Integrations — Easy to Develop, Fast to Deploy, No Changes Required with HB.js

Today’s hybrid IT landscape requires extending the value of mainframe applications to make compelling business applications.

Critical applications and business logic are contained in your CICS environment.

You have invested time and effort to create applications that happen to run on the mainframe. Tossing them aside just to rewrite them is not a good investment. Tapping into these applications, extending the entry points, and enabling newer tenured developers to access the value is a must do.

We’ve learned over the years what approaches do not work well when seeking to integrate with mainframe applications! You could use 3270 terminal emulation and the layout of the fields on the CICS application screens to automate running these CICS applications (sometimes called ‘screen scraping’). While screen scraping can pull results from CICS applications into a more user-friendly environment, these types of integrations are slow, prone to break if there are CICS application changes, and can be expensive — driving up mainframe costs.

What’s a better way to integrate with CICS applications so hybrid applications become more powerful?

Modernize Without Breaking Your CICS Applications

Valuable CICS applications should be used as a distinct advantage.

Instead of focusing on moving your valuable CICS applications off of the mainframe, what if you could API enable them? Allow your CICS applications to integrate with modern web services, front-ends, and even with other CICS applications.

HB.js is the solution for API enabling your CICS applications, allowing you to make these valuable resources readily available for use on any platform, using any integration.

HB.js operates using the following principles:

• No screen scraping
• Easy services development
• Fast services deployment
• No required changes

How HB.js Enables CICS Integrations

HB.js runs inside of CICS, limiting overhead and redundancy and saving CPU time. HB.js is also zIIP-enabled, further lowering mainframe costs. And HB.js is highly performant, with some customers running more than 30 million transactions per day using HB.js.

There’s no requirement to change your CICS application to use HB.js. Moreover, HB.js excels at end-to-end application-level testing, enabling confidence in the reliability and integrity of your existing CICS applications. And when your CICS applications do change, your HB.js-developed services will continue to work because HB.js does not use screen scraping. HB.js uses the key-value pairs made accessible in BMS maps to interact with CICS applications in a resilient way. Screens and fields in the CICS applications can be changed without breaking your HB.js services.

You can use HB.js to navigate complex CICS applications and create HB.js services using JavaScript. JavaScript is used by over 17 million software developers. You can create callable web services for your CICS applications in minutes or hours rather than weeks or months. You can use these web services on any platform, in any manner, with any API. And you can run these web services using DevOps pipelines and standard tools like git, Jenkins, and more.

You can create an HB.js JavaScript service for each CICS application. Or you can create a single JavaScript service that leverages as many CICS applications as you need — to send a single call to the mainframe, where the HB.js service will orchestrate the needed CICS applications and return a single response with data formatted however you need it.

How HB.js Supports Developers

Using the supported HB.js development tools that run in Visual Studio Code (VS Code) and Eclipse, easy HB.js service development and fast deployment are possible for JavaScript developers, even those with limited mainframe knowledge and skills.

HB.js provides an Application Explorer so that developers can learn how existing CICS applications work, discover the important fields on each application screen, and learn how to use the applications with HB.js. Application Explorer provides the information necessary to write HB.js services for existing CICS applications.

The HB.js development tools in VS Code and Eclipse also enable developers to quickly and easily store, compile, and run HB.js services on the mainframe, using their preferred development environment. Services already stored on the mainframe can also be easily retrieved and updated, without touching a green screen.

Unlock the value of your legacy CICS applications while improving your business agility by leveraging HB.js. As a part of the Broadcom Mainframe DevOps Suite, you may already have access! Learn more at
https://www.broadcom.com/products/mainframe/application-development-testing-devops/hostbridge

#HB.js#Mainframe#JavaScript#CICS#zOS#Integration

Co-Authored by Michael Wendel

CICS Integrations — Easy to Develop, Fast to Deploy, No Changes Required with HB.js was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sheree Britt, Associate Vice President, Mainframe Engineering Practice Lead, who’s leading the charge for Mainframe Modernization at TD Bank Group, has been recognized as the Enterprise Leader of the Year by the DevOps Dozen awards!

The award recognizes a strong DevOps leader who guides their team through the challenges of developing and implementing DevOps strategies, policies, culture, and practices to improve software development and delivery.

“Culture change is the most challenging aspect of any transformation, but especially in large, complex organizations. TD’s Sheree Britt shows what a leader can accomplish when you lean into DevOps practices and principles and get the organization excited by early wins and the long-term potential,” said Alan Shimel, lead judge and founder/CEO at Techstrong Group.

Following a distinguished 22-year software engineering career at American Express, Sheree was recruited by TD Bank Group to help modernize the software delivery process across platforms and build a talent pipeline around it. For the past couple of years, she’s been leading the team through innovation and change while successfully maintaining high-quality standards to meet day-to-day demands. By institutionalizing DevOps across platforms, TD benefits from greater business agility, normalized skillsets, and increased digital innovation.

A particular challenge for the mainframe has been the retirement of experienced developers resulting in the need to backfill with staff familiar with contemporary DevOps practices and toolchains (and unfamiliar with legacy tools and practices). Through her modernization efforts, new recruits can now use familiar DevOps tools and practices and spend more time coding and problem-solving.

Sheree has been able to bridge the two worlds by adopting an empathetic approach that addresses the perspectives of both new-to-mainframe talent as well as long-tenured developers with limited experience with DevOps.

Her self-described leadership mission: “Lead with empathy, motivate and help colleagues grow and realize their individual career goals”.

Teamwork Makes the Dream Work

TD’s Mainframe Modernization vision is to develop and equip engineering talent with the knowledge and technical skills necessary to succeed while modernizing the software delivery process. This innovative team spans many geographies including Fort Lauderdale, Toronto, Calgary, and New York.

TD TechCon and Innovation Days

A key element to the team’s success is the open exchange of ideas at internal forums and the freedom to apply these ideas in a controlled environment. TechCon, for example, brings together TD technologists, in-person and remotely, to learn, develop, and enhance their tech acumen and skills.

Partnering for Success

Sheree and her team actively partner with Broadcom to ensure the AppDev process, technology, and culture are progressing together. Sheree is open with her experiences orchestrating her modernization program and in doing so she helps the entire community move forward.

For example, she recently won a Best Session award at the SHARE industry conference for the presentation, “AppDev Modernization: Where Do I Start?” Broadcom’s Vaughn Marshall was a co-presenter in this well-attended and interactive session. The mainframe community benefits when leaders like Sheree share their modernization ‘lessons learned’ (lifts all boats).

Mainframe Leadership

Let’s take time to recognize the incredible progress mainframe visionaries like Sheree are making on their modernization journeys.

Congratulations Sheree Britt! With leadership like yours, the sky is the limit!

Mainframe Engineering Leader Wins Enterprise DevOps Award was originally published in Modern Mainframe on Medium, where people are continuing the conversation by highlighting and responding to this story.