PROJECTS
Most are proprietary IBM z/TPF systems work, so there's no public repo, but ask me more about them and I'd be happy to tell you!
Remote TLS Certificate Expiration Monitor
CC++x86 ASMz/TPF
ProblemLarge z/TPF clients had no way to track expiry of the remote TLS certs their systems handshake with. A silent expiration that they can't control can cause an outage, costing them huge amounts of time and resources.
BuiltCompliance tooling that captures remote client/server TLS certificates after SSL handshake occurs. Certificates are parsed and placed into a hashmap in system heap. A console command lists every stored cert with its expiry; a daily sweep flags anything inside a configurable window and hands it to a customizable user exit so that each client can handle it as their business needs require – catching expirations before they turn into an outage.
Hard partDoing this inside a proprietary OS with tight heap constraints and zero tolerance for leaks. Incorporating real time feedback from our clients to ensure the tooling will work for everyone regardless of their traffic volume.
Parallel I/O & Compression Migration
CC++TPFDF
ProblemThe hierarchical, record-oriented TPFDF database was slow to read at scale, with each record needing to be completely read from disk before the next could be accessed.
BuiltA migration routine converting user selected databases into an indexed and compressed structure–up to 96% faster reads for large databases. Reused existing DF APIs to keep duplication down while also adding custom handling to ensure database integirty in the event of an error. Additionally shipped a full falback migration routine so clients have the option to revert back to the original structure if they choose.
Hard partParsing complex HLASM routines to understand what integrity checks and assignments my custom routine will need to do to keep migrated databases compliant. Ensuring data integrity during migration while simultaneously ensuring the database resides at the same location on disk. Handling complex error processing so clients experience no downtime on their production databases in the event of an error.
Request and Response Headers for HTTP Test Driver
CC++HTTPz/TPF
ProblemOur internal HTTP test drivers could only tack on 4 fixed headers – about 85 bytes total – onto a request or response. That's nowhere close to what's needed to stress-test real-world header loads or edge cases near protocol limits.
BuiltReplaced the fixed header list with size-based parameters that let a caller ask for request and response headers of (near) indeterminate size, up to just under a million bytes. The drivers now split that size into as many max-sized header chunks as needed on the way out, and reassemble and validate the exact byte count on the way back in – growing the effective header budget by well over 10,000x the old fixed-header limit.
Hard partThe underlying header API caps how big any single header can be, so honoring an arbitrary caller-requested size meant chunking it correctly, tracking how many chunks were needed, and reconstructing/validating the exact byte count on both the request and response side.
HTTP/2 Proxy Support
CC++HTTPTLSz/TPF
ProblemAs part of a larger effort to bring HTTP/2 support to z/TPF, proxy connections needed to keep working through TLS proxy servers that only spoke HTTP/1.1 – infrastructure our clients still depended on and that had no way to parse HTTP/2 frames or streams.
BuiltImplemented HTTP/2 proxy support by routing all HTTP/2 proxy traffic through the same CONNECT – established TCP tunnel used by HTTP/1.1, so existing HTTP/1.1 proxy servers (and backwards-compatible HTTP/2 ones) could set up the tunnel without ever needing to understand HTTP/2 frames or streams. Added the logic to both the persistent and non-persistent connection routines, and supported synchronous and asynchronous messages, with zero regressions for existing HTTP/1.1 proxy clients.
Hard partRealizing the CONNECT request method could stay entirely HTTP/1.1 regardless of which protocol version got negotiated afterward – that meant I could hook directly into the existing HTTP/1.1 TLS proxy routine instead of writing new tunnel – setup logic, but getting there took digging into both the HTTP/1.1 and HTTP/2 specs to confirm the CONNECT tunnel was truly protocol-agnostic.
HTTP/2 Emergency Unlock for Socket Locks
CC++HLASMz/TPF
ProblemAn ECB that acquires a lock on a shared socket item may take a catastrophic error while holding the lock and begin dump processing without releasing the lock. Thus, the socket item remains locked indefinitely, even though nothing is using it anymore.
BuiltAdded a field to the ECB that saves the lockword at acquire time and is cleared when the lock is released. Then, a routine invoked during dump processing checks for the presence of that lockword and, if present, releases it before the dump completes – recovering the socket item automatically instead of requiring a manual restart.
Hard partLocks can only be released on the I-stream that acquired them. I needed to spoof the saved lockword to make the lock appear acquired on the dumping I-stream to allow it to be released.
EXPERIENCE
Software Developer Intern – IBM z/TPF
Middleware & Security · Database squad – Poughkeepsie, NY · 2025–present
Built middleware TLS-cert monitoring, resolved a critical bug that hung shared system sockets, and worked directly with clients to scope and redesign features. Converted a full-time offer into a continued internship to pursue my MS.
Software Engineering Intern – Columbia Build Labs (AMLAH)
Backend & system design – New York, NY · 2024–2025
Designed data models, database schemas, and RESTful APIs for scheduling remote real-estate tours, agent availability, and inventory.
Teaching Assistant – Columbia CS
4 courses · 3 professors – 2024–present
TA for Advanced C, C++ Design, Data Structures, and Intro Java. Build grading rubrics in Pygrader, run office hours, and design exams, assignments, and projects.
Research Intern – DitecT Lab (WayCARE)
Prof. Xuan Di – 2024
Extended an existing codebase to deploy and update a full-stack weather-data dashboard.
ABOUT
I'm a systems engineer working on operating systems, security, networking, and databases. These days that means IBM's z/TPF mainframe OS, mostly in C, C++, and assembly. I'm also pursuing an M.S. in Computer Science at Columbia, with a focus on software systems.
Outside of that, I'm usually lifting, playing soccer, reading fantasy/sci-fi, or gaming. If you're curious and want to learn more, contact me below – always happy to chat.