Last summer, I worked on the Zowe Python SDK project with the Zowe team under the Open Mainframe Project at Broadcom’s Pittsburgh office. This summer, I rejoined the team to contribute further on a different project. Arriving in May, I felt a mix of excitement and anticipation—eager to build on my prior experience and dive once again into the world of mainframe development. Just like last time, the team’s warm welcome and collaborative spirit set the tone for an engaging and intensive 12 week journey.
What I Focused On
My work this summer centered on Zowe Native Proto, an open-source, SSH-based protocol designed to expose z/OS operations with minimal server-side configuration. Native Proto simplifies how tools and services interact with the mainframe, aiming to remove the friction traditionally associated with z/OS automation.
My contributions spanned from low-level protocol wrapping to end-to-end service integration—each step designed to help make mainframe resources feel as intuitive and accessible as any modern API.
One of my key responsibilities was building Python bindings for Zowe Native Proto’s existing C++ library. Given z/OS constraints, I chose the Simplified Wrapper and Interface Generator (SWIG) to generate the necessary glue code.
I authored SWIG interface files and created C++ wrapper classes for three core modules. I then wrote test cases to validate that the Python-facing API worked correctly and remained consistent with its C++ counterpart.
With the Python bindings in place, I built a lightweight Flask service to expose Native Proto functionality through Broadcom’s API Mediation Layer (APIML). This service acts as a RESTful interface to the underlying SSH-based mainframe protocol, handling:
-
Authentication
-
Routing
-
Error translation
I also added integration tests to validate the full end-to-end flow and ensure the system would remain stable as future changes rolled in.
Overcoming Challenges
Here are a few of the technical challenges I faced—and how I solved them:
-
Packing Misalignment. Conflicting packing strategies between compilers (xlc++ vs. xlclang++) caused crashes and memory corruption.
Solution: I inspected dumped memory layouts to identify the mismatch and used conditional macros to align data structures properly across compilers.
-
Encoding Conflicts. z/OS defaults to EBCDIC encoding, while Python expects ASCII—leading to garbled text and mismatched function signatures.
Solution: I standardized the exported symbol interface using C linkage and implemented explicit string conversions between EBCDIC and ASCII.
-
Limited Automation Tools on z/OS. Many popular binding generators and service frameworks were incompatible with z/OS.
Solution: I selected SWIG as the most viable option and fine-tuned its workflow for our build environment. I also chose Flask for its simplicity and compatibility with our API goals.
-
SSL Setup in APIML. Misconfigured certificates blocked requests through the gateway.
Solution: I iteratively adjusted the SSL settings, collaborated with platform teams, and validated the final configuration using integration tests.
Made Possible By
None of this would have been possible without the incredible support from my team in Pittsburgh. Senior engineers helped me navigate onboarding, brainstorm solutions, and provided thoughtful, constructive code reviews. Their professionalism, collaboration, and patience helped me grow throughout the summer.
Looking back, my time with Broadcom this summer gave me more than technical skills. I learned how to:
Along the way, I deepened my experience with C, C++, z/OS toolchains, and Flask-based APIs—while also gaining a new appreciation for the power of open collaboration in open-source communities.
I'm grateful for this experience, and I look forward to applying everything I've learned to whatever comes next.