Note: The views expressed in this article are my own and do not necessarily reflect those of IBM.

“I’ve entered the mainframe.”

In movies, that’s usually the big moment in a hacking scene: our shades-and-trenchcoat-wearing hero has breached the villains’ systems and gained access to their secrets. It’s a line that’s become shorthand for high-tech intrigue.

But, for me, a mainframe is just part of my everyday work.

Despite their reputation as relics of a bygone era, mainframes remain some of the most important computers in the world. Mainframes process roughly 90% of credit card transactions worldwide. The latest IBM model, the IBM z17, handles up to 35 billion transactions per day. Seventy-one percent of the Fortune 500 run on mainframes; 92 of the world’s top 100 banks use IBM Z.

Scale like that changes the shape of failure. When a core banking platform stumbles under peak load, the consequences are not cinema: millions of customers locked out, payments delayed for weeks, regulators issuing fines in the tens of millions. The culprits are never really unexpected, either: untested changes or under-tested capacity. A tragedy of the commons, where the shared thing is trust and the bill comes due at peak load.

As a software test engineer on z/OS, that’s one of the most important parts of my job: know what the system handles before payday.

Driving tests at the source

IBM has long-standing load testing tools purpose-built for the platform: TPNS (Teleprocessing Network Simulator), first released in 1976, and its successor IBM Workload Simulator for z/OS (WSim). Both are deep platform tools, built for engineers who live on the system. As z/OS exposes more workloads through modern interfaces and development teams bring web-native workflows to the platform, there’s a case for a tool that meets them where they are.

k6, the open source load and performance testing tool, speaks that language: tests as code, version-controlled alongside the application, scripted in JavaScript, triggered from a CI pipeline, and results streaming to a Grafana dashboard. It’s the kind of tooling modern development teams already know how to operate.

k6’s Go engine stays lean under load: roughly 256 MB versus JMeter’s 760 MB in one third-party comparative study, enabling far higher concurrency per machine, though results vary by workload.

In banking, government, and regulated industries, mainframe environments are routinely air-gapped: no external network access and no reaching out to a package registry or a remote test runner. Every tool in the pipeline has to live on the platform itself, which means the load generator does too. On zCX (z/OS Container Extensions), k6 can run inside the mainframe’s own container runtime. Through the batch job scheduler, load tests become jobs that run alongside production workloads. The platform is modern. The tooling should be too.

One problem: k6 didn’t run on IBM Z’s s390x architecture. IBM Z has used s390x since the System/390 era; it’s a different instruction set entirely from the x86 chips in most developer laptops and cloud VMs, so building k6 natively on the platform wasn’t straightforward. IBM has been deliberately expanding the shell-first tooling story on z/OS: IBM Open Enterprise Foundation for z/OS (OEF) ships Git, Bash, Curl, Vim, and more as a no-charge component of z/OS, and Z Open Automation Utilities (ZOAU) exposes z/OS facilities through UNIX-style commands and Python APIs. A z/OS developer should be able to type k6 run the same way they type curl, git, or bash.

Go-ing Native

IBM z/OS is not a UNIX OS, but it has a POSIX-compliant layer called z/OS UNIX System Services (USS), with SSH access, familiar tooling, and an alternative way of interacting with the mainframe’s resources beyond a green screen. IBM’s Open Enterprise SDK for Go, generally available since January 2021, makes Go compilation native on z/OS: binaries that run directly on the hardware, no emulation, no containers.

I fork k6, clone it to my USS home directory, and kick off a go install. Two build errors, two fixes. First, afero (a filesystem abstraction library that k6 depends on) was missing z/OS in its list of supported platforms. In Go, build constraints are the mechanism that controls which platforms a file compiles for, and afero’s simply didn’t include zos:

  
// Before    
//go:build aix darwin openbsd freebsd netbsd dragonfly    
         
// After    
//go:build aix darwin openbsd freebsd netbsd dragonfly zos  

That fix was subsequently merged upstream (spf13/afero#384).

Then ui_unix.go needed the same treatment: k6’s terminal progress bar redraw logic listed every supported Unix-like OS except z/OS. One more line:

// Before   
//go:build darwin || dragonfly || freebsd || linux || netbsd || openbsd    
         
// After    
//go:build darwin || dragonfly || freebsd || linux || netbsd || openbsd || zos  

That fix was merged upstream too (grafana/k6#2892).

❯ go install    
❯ $GOPATH/bin/k6    
         
             /\      |‾‾| /‾‾/   /‾‾/    
        /\  /  \     |  |/  /   /  /    
       /  \/    \    |     (   /   ‾‾\    
      /          \   |  |\  \ |  (‾)  |    
     / __________ \  |__| \__\ \_____/ .io    

Two build tag additions. k6, now running natively on IBM Z.

k6 is now available in zopen, the community package manager for z/OS. I also provide prebuilt s390x binaries for IBM Z (including zLinux) on my personal fork of k6.

I’d bank on it

For the test target, I wanted something that looks like real production: COBOL programs, REST endpoints, and CICS (Customer Information Control System) transactions. CICS is IBM’s transaction processing middleware, the runtime that has handled the world’s core banking workloads for decades, sitting between the network and the underlying COBOL programs. IBM’s open source CICS Banking Sample Application (CBSA) exposes a realistic set of banking operations through REST endpoints backed by actual COBOL programs, making it a faithful stand-in for a production core banking stack.

I based the transaction mix on the TPC-C specification, the industry-standard benchmark for database-heavy transactional workloads like banking: roughly 65% reads, 35% writes. Mapped to CBSA’s endpoints:

Custom metrics separate read and write latency. One detail worth calling out: the IBM z/OS Connect endpoint returns 200 OK regardless of whether the underlying CICS transaction succeeded. The actual result lives in a field in the response body, so paySuccessRate checks the application-level outcome directly rather than relying on the HTTP status code.

 import { Rate, Trend, Counter } from "k6/metrics";    
         
 const inqDuration    = new Trend("cbsa_inq_duration_ms",  true);    
 const payDuration    = new Trend("cbsa_pay_duration_ms",  true);    
 const paySuccessRate = new Rate("cbsa_pay_success_rate");    
 const txnTotal       = new Counter("cbsa_transactions_total");    
 const readRate       = new Rate("cbsa_read_rate");    
         
 export const options = {    
      vus: 10,    
      duration: "10s",    
      thresholds: {    
        "cbsa_inq_duration_ms":  ["p(95)<250"],    
        "cbsa_pay_duration_ms":  ["p(95)<350"],    
        "cbsa_pay_success_rate": ["rate>0.95"],    
        "http_req_failed":       ["rate<0.01"],    
    },    
  };  

The numbers, Mason!

A single k6 instance is documented to generate up to 300,000 requests per second. For context on what it’s hitting: a single LPAR (a logical partition, which is an isolated slice of mainframe capacity) has been measured in an IBM Redbooks study at up to 174,000 CICS transactions per second under benchmark conditions. Running k6 on the same hardware removes the network hop between generator and target, giving better latency accuracy and keeping the test inside the same operational boundary as the system under test.

Let’s see it in action

Here is k6 running natively on z/OS UNIX System Services, targeting CBSA’s IBM z/OS Connect endpoints: account inquiries, customer lookups, payment transactions, and live CICS backend:

The console output shows real-time transaction logs using the actual operation names from the underlying COBOL programs. The k6 summary table at the end breaks out the custom metrics alongside standard HTTP statistics.

Hostnames, endpoints, and identifiers have been obfuscated for security and compliance.

Punchcards, protocols, and plugins

k6’s--out influxdb and native Prometheus remote-write stream z/OS test metrics straight into a Grafana dashboard. With k6 as a native binary on z/OS, it slots naturally into the platform’s batch job system. On z/OS, Job Control Language (JCL) is the decades-old scripting format for submitting work to the batch scheduler, the same system that runs nightly reconciliation jobs and end-of-day processing for banks worldwide. Here’s a k6 load test submitted as a batch job via JCL:

//K6LOAD   JOB (ACCT),'K6 CBSA LOAD TEST',    
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID    
//*-------------------------------------------------*    
//* Run k6 load test as a batch job                 *    
//*-------------------------------------------------*    
//STEP1    EXEC PGM=BPXBATCH    
//STDPARM  DD *    
  SH /home/user/go/bin/k6 run \    
     --vus 10 --duration 60s \    
     --out influxdb=http://grafana.internal:8086/k6 \    
     /home/user/banking_load_test.js    
/*    
//STDOUT   DD SYSOUT=*    
//STDERR   DD SYSOUT=*    

The same 80-column syntax inherited from punchcards, now driving a load test that streams metrics to Grafana.

The longer play is k6 as a complete end-to-end test framework for z/OS. I wrote xk6-tn3270 toward that end: a k6 extension that adds TN3270 emulation. TN3270 is the terminal protocol used to drive the text-based “green screen” interfaces that z/OS applications have exposed since the 1970s. It lets teams already familiar with the platform drive those workflows through the same scripting model they’d use for REST.

Add enough xk6 extensions and one tool covers REST, 3270, SSH, MQ, and so on. As of k6 2.0, the s390x port ships with the new k6 x mcp subcommand, which runs k6 as an MCP server so an AI agent can drive load tests directly.

If you want to try this yourself, CBSA is on GitHub, ZXplore covers the platform fundamentals for free, and k6 on z/OS is one zopen install k6 away.

There you have it: modern load testing, running natively on the platform that has powered global banking for over sixty years.

The hardware earned its reputation for resilience. k6 amplifies it.

Big Iron under load: How to test IBM Z mainframes with k6 was originally published in Unprompted, by Grafana Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

This scene runs on 20 watts. A gaming PC draws 150–200+ watts just for the GPU. Switch 2’s entire system uses a fraction of that power.

Portable gaming has defined my relationship with the medium. The DS Lite sparked it in childhood. Today, my Switch and Steam Deck turn subway commutes into gaming sessions. There’s something magical about high-fidelity experiences that fit in a bag, and I’ll trade max settings for portability every time.

The Switch nailed the hybrid concept: seamless transitions between handheld and TV. My gaming PC sits at home pulling hundreds of watts. What fascinates me more is what engineers achieve within tight power budgets. Give me 10 watts and ingenuity over 200 watts of brute force.

Which explains why I’ve lurked in hardware speculation threads for years, parsing every leaked specification and blurry PCB photo. As a software developer with five years in the industry, I’ve watched these leaks through the lens of someone who codes for a living but nerds out over hardware constraints. Now the console exists, and I’m evaluating it through a new lens.

I’m now studying computer engineering in grad school, the classic geekdom to academia pipeline. The same day of my first Computer Architecture lecture, where my professor discussed domain-specific acceleration and thermal constraints, I got home and booted Star Wars Outlaws on Switch 2. Theory became sweet, sweet practice: Moore’s Law dead, energy efficiency paramount, specialized hardware compensating for modest clocks. The lecture posited it, Outlaws proved it.

T239’s efficiency isn’t luck, nor are its demonstrative games miracles. It’s deliberate architectural choices prioritizing watts-per-frame over raw teraflops. This article examines how those choices enable current-gen gaming in a portable form factor, acknowledging the challenges, caveats, and creativity.

This won’t exhaustively compare Switch 2 to Steam Deck or PS5. Architectural differences (ARM vs x86, console vs PC, Nvidia vs AMD) and developer experience confound direct comparisons. A $450, 1.4 cm tablet with 2020–2022 components won’t match PS5’s raw power. That’s not the point. The point is showing how architectural advantages deliver compelling experiences within thermal constraints that enable true portability.

The Hardware

Switch 2 runs on Nvidia’s T239, built on Samsung’s 8N process — a hybrid of 10nm and 8nm technology confirmed by die analysis. Key specs:

• GPU: 1536 CUDA cores, 1007 MHz docked / 561 MHz handheld
• CPU: 8 ARM Cortex-A78C cores, 1.0 GHz docked / 1.1 GHz handheld (6 cores for games)
• Memory: 12GB LPDDR5X at 102.4 GB/s (9GB for games)
• Power: ~20W docked / ~12W handheld

The specs reflect modern mobile technology: LPDDR5X RAM and UFS 3.1 storage match current flagship phones, while microSD Express support (still uncommon in 2025) enables fast external storage. The GPU and CPU architectures are 2020s-era — Ampere-Ada hybrid and Cortex-A78C — balancing proven efficiency with features modern engines expect.

Architectural Advantages

T239 has features that aid it in punching above its weight, including but not limited to:

• 12 Second-generation RT Cores for hardware ray tracing
• 48 Third-generation Tensor Cores for DLSS
• Mesh shader support for efficient geometry processing
• File Decompression Engine for hardware asset decompression

Die analysis and observations from public Git repositories revealed optimizations beyond standard Ampere implementations. The chip includes first-level clock gating from Ada Lovelace, which powers down unused functional units at microsecond timescales — likely improving power efficiency significantly. The GPU layout has separated TPCs (texture processing clusters), which borrows from Ada rather than Ampere, demonstrating a forward-thinking, ‘hybrid’ approach to chip design. A pure Ada chip might have been more cutting-edge, but more expensive and with diminishing returns — while an Ampere chip with Ada features can keep costs down while retaining the same featureset as the current-gen consoles (both Ampere and RDNA2 are from 2020 and are DirectX12 Ultimate compliant).

This contrasts sharply with the original Switch’s stock Tegra X1 — a mobile GPU stretched thin by hybrid demands it wasn’t designed for. As Nvidia CEO Jensen Huang noted at launch: “This chip brings together three breakthroughs: the most advanced graphics ever in a mobile device, dedicated AI processors, and ultra low power operation.”

Power Efficiency: The Real Story

Digital Foundry’s power analysis running Cyberpunk 2077’s benchmark reveals the efficiency advantage in concrete terms:

• Switch 2 docked: 20–22W total system power
• Steam Deck OLED: 29–31W (same benchmark, matched settings)
• PlayStation 5 Slim: ~220W

Switch 2 uses two-thirds the power of Steam Deck OLED while delivering superior docked performance. In handheld mode, Switch 2 draws ~9W while Steam Deck pulls 24–25W — one-third the power while maintaining competitive performance in optimized titles.

The 8nm Question

Samsung’s 8nm process sounds ancient compared to the 7nm TSMC node in Steam Deck, Series S, and other PC handhelds / current-gen consoles, raising reasonable questions about efficiency. But process node comparisons between Switch 2 and x86 handhelds miss a fundamental architectural difference: the combination of ARM CPU architecture and Nvidia’s Ada Lovelace GPU optimizations delivers superior efficiency.

ARM Cortex-A78C cores consume significantly less power per operation than x86 equivalents at similar performance levels — this is why smartphones and tablets universally use ARM. T239’s Ada Lovelace features like first-level clock gating (powering down unused units at microsecond timescales) and separated texture processing clusters further reduce power draw. Hardware-accelerated DLSS and RT further contribute to this by spreading out work between dedicated computational units, rather than pumping clocks into shader cores to force out a prettier image. Switch 2 achieves its efficiency through architecture rather than brute-force lithography. The 8nm node suffices because the underlying design is inherently power-conscious.

The Bandwidth Question

The 12GB LPDDR5X runs at 102.4 GB/s — modest compared to Xbox Series S’s 224 GB/s peak. That comparison ignores how the data actually moves. Effective bandwidth exceeds raw specifications thanks to specific architectural features:

GPU compression: According to Nvidia’s GA102 (Ampere) whitepaper, delta color compression and lossless framebuffer compression have been shown to reduce memory traffic by 40–50% per frame on desktop implementations. While T239’s exact compression efficiency isn’t publicly documented, similar techniques should significantly reduce actual bandwidth required for rendering.

File Decompression Engine: T239 includes hardware-accelerated FDE that unpacks LZ4 compressed files from game packages, offloading decompression work that would otherwise consume CPU cycles. Combined with UFS 3.1 storage, this makes asset loading faster and more power-efficient.

Raw bandwidth comparisons are misleading without accounting for compression advantages and efficient data pipelines built into the architecture.

DLSS (Deep Learning Super Sampling) is T239’s most important feature. The technology uses AI to reconstruct high-resolution images from lower-resolution input, dramatically reducing GPU workload.

The math is simple: rendering at 720p instead of 1080p reduces pixel count by 44% : 44% fewer pixels to shade, texture, and light. Tensor Cores reconstruct missing detail using temporal data and neural networks, producing output approaching native quality.

Digital Foundry’s analysis revealed Switch 2 uses two distinct DLSS implementations:

- Standard CNN (Convolutional Neural Network) model (matching PC quality): Cyberpunk 2077, Street Fighter 6
- “Tiny DLSS” (~50% cheaper in frame time): Fast Fusion, Star Wars Outlaws

The lighter variant enables higher resolution targets impossible with standard DLSS given T239’s power budget. Fast Fusion achieves 4K/60fps by rendering at 648p using lighter DLSS. The trade-off: reduced reconstruction quality on moving objects, though static scenes remain sharp.

Even at aggressive upscaling ratios (540p → 720p in handheld mode), output remains clean in motion. DLSS represents domain-specific machine learning in action — AI purpose-built for rendering that aligns perfectly with Nintendo’s power-efficient design philosophy.

Cyberpunk 2077: Day-and-Date Parity

Digital Foundry’s Cyberpunk analysis revealed impressive results for a launch title. Switch 2 targets 30fps at 1080p docked using custom settings blending high, medium, and low presets with bespoke solutions. Internal resolution fluctuates between 720p and 1080p depending on scene complexity, with DLSS reconstructing the final output.

CDPR’s approach reveals T239’s strengths. Rather than uniformly cutting quality, they developed custom solutions: bespoke shadow cascades, modified screen-space reflections, texture streaming rebuilt for UFS 3.1 storage and hardware decompression. The result: texture quality matching or exceeding Series S in several scenes despite lower memory bandwidth (Switch 2 does have 2 GB more total RAM than Series S).

Key findings:

• Texture quality matches/exceeds Xbox Series S in multiple scenes
• Custom screen-space reflections and shadow cascades
• Stable performance in most areas, mid-20s drops in dense Dogtown districts

I put over 80 hours into Cyberpunk on Switch 2. The seamless transitions between handheld and docked modes — picking up a mission on the TV, continuing it on the Metro-North train, finishing it back home — exemplify the hybrid concept’s strength. Yes, it runs at 30fps with occasional drops. Yes, it’s rendering at lower resolutions than PS5. But the convenience of that portability, combined with DLSS maintaining image quality, made it my preferred way to experience Night City despite owning a gaming PC.

The CPU Question

The Phantom Liberty expansion’s Dogtown (dense crowds, complex AI) drops to mid-20s where Series S holds 30fps. Six ARM cores clocked at 1.1 GHz must be weak compared to the high-clocked x86 cores in PC handhelds and stationary home consoles, right?

Reality is more nuanced: developers need time adapting to ARM after years optimizing for x86. The original Switch’s Witcher 3 port demonstrated what aggressive CPU optimization achieves on ARM architecture — Saber Interactive eliminated busy-wait loops, moved cloth simulation to GPU (3–5x faster than CPU), leveraged ARM-specific features like shared L2 cache, and applied cache-friendly memory access patterns. The result: stable 30fps in a game that seemed impossible on Switch 1’s hardware.

Switch 2’s eight Cortex-A78C cores (six available to developers) offer significantly more headroom than Switch 1’s four cores (three available). Current-gen ports can achieve stable performance once developers adapt their optimization strategies to ARM architectures — it’s a learning curve, not an insurmountable barrier. And don’t forget the File Decompression Engine offloading work from the CPU!

The fact that Cyberpunk launched day-and-date with other platforms — handled in-house by CDPR rather than outsourced to port studios — demonstrates Nintendo’s improved third-party support compared to Switch 1’s late, reduced-quality ports.

Star Wars Outlaws: Ray Tracing on Battery Power

Star Wars Outlaws represents, at least to me, a more impressive technical achievement than Cyberpunk: a current-gen-only game built entirely around hardware ray tracing, running on ~10W handheld / ~20W docked.

Outlaws runs at 30fps in both docked and handheld modes. Docked: 1080p output, DLSS upscaling from ~720p internal. Handheld:** 720p output, DLSS upscaling from ~540p internal. The 720p internal resolution in docked mode means the GPU renders 2.07 million pixels per frame — 44% fewer than native 1080p. DLSS reconstructs the missing detail using temporal data and AI inference. The game maintains a locked 30fps with occasional drops in dense areas like Toshara’s main city.

Digital Foundry’s analysis revealed impressive technical achievements. Switch 2 retains hardware ray tracing for diffuse global illumination and reflections — the same core rendering features present on PS5 and Series X, albeit at lower resolution with more noise in the lighting solution. Recent patches have improved texture quality and image stability.

More remarkably, performance proved superior to Series S in some scenarios. While both target 30fps, Series S exhibits frame pacing issues that make camera movement feel stuttery even when the frame counter shows 30fps. Switch 2 maintains consistent frame delivery — a locked 30fps feels smoother than an inconsistent 30fps. Digital Foundry concluded: “Performance is arguably worse on Microsoft’s junior console than on Nintendo’s hybrid.”

Despite Digital Foundry’s reservations about “Tiny DLSS,” I’ve found through 30+ hours with Outlaws that image quality holds up impressively both in stills and in motion, even on my 65-inch 4K television. The lighter DLSS implementation demonstrates remarkable stability for its performance cost.

The ray-traced bounce lighting captures Star Wars’ visual language — illuminated darkness, glowing panels in shadow. RT reflections run at lower resolution but integrate cohesively. Ubisoft maintained the game’s visual identity rather than compromising it for the platform.

Outlaws demonstrates what distinguishes Switch 2 from its predecessor: not just running current-gen games with cutbacks, but running current-gen rendering techniques. The game wasn’t designed to run without ray tracing — it’s the foundation of Snowdrop Engine’s lighting model. The fact that it runs at playable framerates on battery power represents the architectural advantage in action. This isn’t a downport — just a port. Switch 2 is a current-gen portable console.

It’s all in the architecture: the second-generation RT Cores in T239 are more efficient than Turing’s first-generation implementation. Nvidia’s GA102 architecture whitepaper notes 2x ray/triangle intersection performance compared to Turing, plus support for concurrent ray tracing and compute operations — keeping both RT Cores and shader cores active simultaneously rather than leaving units idle between passes.

Port Quality: Developer Commitment Matters

Switch 2’s early library demonstrates a clear pattern: port quality tracks with developer investment and familiarity with the platform’s specialized features, not fundamental hardware limitations.

Final Fantasy VII Remake Intergrade exemplifies thoughtful optimization. Digital Foundry called it “the best-looking thing I’ve seen on Switch 2 so far.” Director Naoki Hamaguchi confirmed the port uses PS5 lighting unchanged — “the crucial factor in terms of graphics quality” — while optimizing fog and post-processing for T239’s power constraints. The Switch 2 version retains PS5’s enhanced lighting model, improved textures, and volumetric fog implementations while running at 1080p/30fps docked. This isn’t a PS4 port scaled up, it’s a PS5 port scaled intelligently, preserving the visual elements that define the game’s cinematic presentation.

Persona 3 Reload demonstrates the opposite conundrum. The game launched October 2025 at 30fps with significant framepacing issues that players described as “choppy” and “jarring,” despite maintaining a stable framerate. The port notably doesn’t utilize DLSS — Switch 2’s machine learning upscaling capabilities — which baffled reviewers given that CDPR, Ubisoft, and Square Enix successfully implemented DLSS in far more demanding titles. Reports suggest the resolution target remains 1080p in both modes despite the docked GPU boost, further indicating underutilization. Atlus explicitly stated they “prioritized delivering the Switch 2 version to everyone as quickly as possible” over optimization — a rush to market that DLSS implementation and proper framepacing could have addressed.

The variance in port quality reflects the platform’s learning curve and developer priorities, not impassable hardware constraints. Well-optimized Switch 2 ports aren’t ‘impossible ports’ or technical miracles — they’re simply ports. This represents a generational leap: Switch 2 is a current-gen portable console, not a last-gen device struggling with modern titles. Keep expectations in check as usual — not every developer has the time or resources to maximize hardware potential, and obviously, a portable drawing 20W can’t match a 220W home console.

But when studios invest the engineering resources (custom ARM optimization, DLSS integration, proper power management), Switch 2 delivers current-gen experiences at a fraction of the power consumption. That trade-off — maximum fidelity for portability — is precisely the point.

What This Means Going Forward

Five months into Switch 2’s lifecycle, developers are still learning the hardware. Early ports like Outlaws and day-one Cyberpunk show what’s possible with conservative targets. Future titles will push further as developers optimize for ARM CPUs and exploit T239’s architectural advantages.

More compute-intensive modern games may actually fare better on Switch 2 than lighter titles. Games designed around GPU compute shaders, hardware decompression, and AI upscaling naturally leverage Ampere’s strengths, while older engines built for different architectures may struggle without substantial porting work.

Assassin’s Creed Shadows arrives December 2025 — a demanding current-gen open-world game targeting the platform just seven months post-launch, demonstrating developers are treating T239 as viable hardware for current-generation engines. Indiana Jones and the Great Circle (Spring 2026) is similarly RT-mandatory with no rasterized fallback, demonstrating confidence in T239’s RT cores and DLSS capabilities. Resident Evil Requiem (February 2026) is an incredible statement — the next mainline Resident Evil game, arriving day-and-date with the other console ports, using ray-traced global illumination with DLSS upscaling. Capcom’s director stated “even we were surprised when we first saw it, how beautifully it ran.”

First-party showcases will demonstrate what’s possible with full hardware knowledge and multi-year optimization cycles. The combination of Nvidia’s AI upscaling, efficient memory architecture, hardware-accelerated decompression, and custom power management creates a platform that delivers current-gen gaming experiences at a fraction of the power consumption.

At the End of the Day

Switch 2 runs demanding titles at ~10W handheld / ~20W docked versus 150–200W on PC. That efficiency stems from architectural decisions: DLSS reconstruction, hardware ray tracing, unified memory with compression advantages, hardware decompression offloading CPU work, and purpose-built silicon designed around these features from day one.

Star Wars Outlaws, a current-gen game built entirely around hardware ray tracing, runs at playable framerates on battery power. That’s not a miracle port. It’s proof the architecture works as designed.

I carry this device in my messenger bag. It runs games designed for 200W GPUs. That gap exists because Nintendo built the entire system — silicon, APIs, developer tools — around DLSS, hardware decompression, and power efficiency from the start. Switch 2 fights battles on multiple fronts: thin and light with mass appeal, receiving current-gen ports at reasonable settings, while making a strong argument for its 450 USD price tag in spite of sticker shock. It’s accomplished all three. The console was designed WITH these features from day one — DLSS, RT cores, architectural optimizations — not as crutches to salvage weak specs. The best showings will be software leveraging all acceleration features. Beautiful results in the palm of your hand.

Sources

• Digital Foundry, “Switch 2 Hardware Review” (October 2025)
• Digital Foundry, “Star Wars Outlaws Switch 2 Technical Analysis” (September 2025)
• Digital Foundry, “Cyberpunk 2077 Switch 2 Tech Review” (June 2025)
• Digital Foundry, “Nintendo Switch 2 DLSS Image Quality Analysis” (October 2025)
• Digital Foundry, “Switch 2 vs Steam Deck Cyberpunk 2077 Benchmarked” (June 2025)
• Digital Foundry, “Nintendo Switch 2: Final Tech Specs and System Reservations Confirmed” (May 2025)
• Nvidia Corporation, “NVIDIA Ampere GA102 GPU Architecture Whitepaper” (2020)
• Geekerwan, “This is Nintendo Switch 2’s CPU!” (June 2025)
• Nintendo of America, “Creator’s Voice Special Edition — Nintendo Switch 2’s Custom Processor” (June 2025)
• Roman Lebedev (Saber Interactive), “‘Witcher 3’ on the Nintendo Switch: CPU & Memory Optimization” GDC Talk (2020)
• Famiboards Thread, “Future Nintendo Hardware & Technology Speculation and Discussion” (2022–2025)

Recall from our previous adventure the need to simulate a high volume of transactions on an IBM Z mainframe. As industry leading machines, these massive computers cannot buckle under the load of millions of concurrent requests and responses, and as mainframe testers it becomes our responsibility to simulate this type of workload to preemptively spot and zap out issues.

In my former tango with Locust, I deployed it for HTTP/S request testing, as it is well-suited out of the box to handle a hefty amount of concurrent GET, POST, PUT, and other such methods, submitted to an API endpoint. However, mainframes have several entrypoints to connect and execute functions on — besides HTTP/S, there are also web GUIs, FTP, SSH, and the classic Telnet protocol.

IBM 3270 is what is commonly known as the ‘green-screen’ terminal, and is the legacy interface for interacting with IBM mainframe software. Predominant z/OS applications such as Interactive System Productivity Display (ISPF) and System Display and Search Facility (SDSF) are only accessible through a 3270 emulator session connected via Telnet.

The following interface is of Telehack.com, a functional emulation of a classic green-screen interface that offers some toy applications, including cowsay .

Connected to TELEHACK port 121

It is 10:03 pm on Sunday, February 9, 2025 in Mountain View, California, USA.
There are 119 local users. There are 26648 hosts on the network.

May the command line live forever.

Command, one of the following:
  2048         ?            a2           advent       aquarium     basic
  cal          calc         callsign     cat          ching        clear
  clock        date         delta        diff         eliza        factor
  figlet       file         fnord        head         help         ipaddr
  joke         liff         mac          md5          more         morse
  netstat      newuser      notes        octopus      pig          ping
  pong         primes       rainbow      rand         recover      rfc
  rig          roll         rot13        run          salvo        starwars
  sudoku       tail         today        typespeed    units        uptime
  users        uumap        uuplot       weather      when         zc

More commands available after login. Type HELP for a detailed command list.
Type NEWUSER to create an account. Press control-C to interrupt any command.
.

The UI of a 3270 application lacks the graphical elements one might expect of a modern application, being built up of text and characters that are transmitted via a terminal, lines and blocks being formed from underlines, bars, and slashes. This has the advantage of producing lightweight programs that can still offer a ‘visual’ interface, and the learning curve is small for those already comfortable with keyboard based navigation. Instead of entering commands via a text buffer such as in an SSH session, input is accepted at certain coordinates within the display grid.

Thankfully, modern libraries exist that provide clean APIs for creating a 3270 session, one of which is `py3270`:

from py3270 import Emulator
em = Emulator()

em.connect('3270host.example.com')
em.fill_field(17, 23, 'mylogin', 8)
em.fill_field(18, 23, 'mypass', 8)
em.send_enter()

# if your host unlocks the keyboard before truly being ready you can use:
em.wait_for_field()

# maybe look for a status message
if not em.string_found(1, 2, 'login successful'):
    abort()

# do something useful

# disconnect from host and kill subprocess
em.terminate()

Note how specific coordinates are provided to emulator functions such as `fill_field` and `string_found`, in order to make the most of 3270 automation, one must already have an understanding of the positioning of desired elements on the terminal.

Here’s some sample code to connect to telehack:

em.connect('telehack.com')
em.wait_for_field()
em.send_string("cowsay")
em.wait_for_field()
em.send_string("cowsay hello")
em.save_screen("telehack.html")
em.terminate()

Running this script and viewing the generated .HTML will reward us with:

.cowsay hello
 _______ 
< hello >
 ------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Note how the scripting for 3270 is ‘step-by-step’, with the user waiting for an input field and submitting commands one at a time. Those who are familiar with browser automation such as Selenium WebDriver may feel right at home, as this type of careful puppeteering is necessary when dealing with what is essentially a graphical user interface. I highly recommend manually performing tests to clearly identify the discrete instructions needed before diving into automation.

Now that we’ve established the ‘unit’ case, let’s return to the promise of Locust — commandeering a swarm of users to rampage on a server, slamming it with requests to emulate hectic real-world scenarios. But if Locust is primarily intended for HTTP/S testing, then where does the classic 3270 fit in?

A peek in the Locust documentation reveals that it “can be extended to test almost any system”, and indeed repositories like locust-plugins host extensions that enable FTP, Selenium, Kafka, etc. load testing.

Since Telnet is just another connection protocol, and we have a handy Python interface to launch 3270 sessions, let’s dive right in and extend Locust. By following the lead of the given Locust plugins, we can write a wrapper around the base `User` and create hooks for the connection to be made:

class tn3270User(User):
    abstract = True

    def __init__(self, environment):
        super().__init__(environment)
        self.client = tn3270Client(environment=environment)


class tn3270Client:
    def __init__(self, environment):
        self.environment = environment
        self.emulator = None

    def connect(self, user=None, password=None, port=23, timeout=30, trace=False, tracefile=None):
        self.user = user
        self.password = password
        self.port = port
        self.timeout = timeout
        self.tracefile = tracefile
        if trace:
            self.emulator = Emulator(visible=False, timeout=self.timeout, args=["-trace", "-tracefile", self.tracefile])
        else:
            self.emulator = Emulator(visible=False, timeout=self.timeout)
        self.emulator.connect("y:%s:%d" % (self.environment.host, self.port))

This `tn3270Client` can now be cleanly evoked by a Locustfile:

class DemoTn3270User(tn3270User):
    def on_start(self):
        self.environment.host = "telehack.com"
        self.client.connect()
        self.client.emulator.wait_for_field()
        self.client.string_wait("Type NEWUSER to create an account.")
        self.client.emulator.wait_for_field()
        self.client.emulator.send_string("cowsay")
        self.client.emulator.send_enter()

    @task
    def run_command(self):
        self.client.emulator.wait_for_field()
        self.client.emulator.send_string("cowsay hello")
        self.client.emulator.wait_for_field()
        # Pretty prints the current screen

— and initiated from the command line as usual, e.g. locust -f locustfile.py -u 10 -t 60, which will launch the above script with 10 virutal users and run for 60 seconds. Upon start, each virtual user will instantiate their own 3270 emulator that connects to telehack.com and enters the `cowsay` program, and the repeated task that happens on each actor tick is the submission of `cowsay hello`. This results in 10 agents sending repeated requests to the machine that exercises the `cowsay` function. That’s a lot of cows.

This, of course, is a very rudimentary example. With the versatility and extensibility of scripting in Python, as well as Locust’s valuable features like distributed testing, there are numerous directions one could take this. On an actual IBM Z mainframe, one could use this as a template to script interactions with components such as DB2, CICS, RACF, and so on. Not just automating the behavior of one developer, but also the myriad of transactions that could occur on a typical enterprise system.

So long as modern developers continue to engineer extensions, green-screen interfaces will continue to live on. Even though software is moving towards more programmatic directions, such as via REST APIs, and more accessible UIs on a web browser, there is no denying how much infrastructure is sustained on applications that rely on 3270 interaction. These can still receive the care and attention they deserve without having to compromise on our desire for modernization.

Contrary to popular belief:

```
 ______________________________________________ 
< "This dino can still learn some new tricks!" >
 ---------------------------------------------- 
\                             .       .
 \                           / `.   .' "
  \                  .---.  <    > <    >  .---.
   \                 |    \  \ - ~ ~ - /  /    |
         _____          ..-~             ~-..-~
        |     |   \~~~\.'                    `./~~~/
       ---------   \__/                        \__/
      .'  O    \     /               /       \  "
     (_____,    `._.'               |         }  \/~~~/
      `----.          /       }     |        /    \__/
            `-.      |       /      |       /      `. ,~~|
                ~-.__|      /_ - ~ ^|      /- _      `..-'
                     |     /        |     /     ~-.     `-. _  _  _
                     |_____|        |_____|         ~ - . _ _ _ _ _>
```

Ticks by Telnet: Load Testing IBM Z Mainframe Terminals with py3270 and Locust was originally published in Theropod on Medium, where people are continuing the conversation by highlighting and responding to this story.

So lets take a step back, a deep breath, and look at two recent initiatives in the mainframe space that live up to the ‘open’ name — Z Open Automation Utilities and z/OS Open Tools. In specific, we’ll take a look at how the tooling offered by these projects can streamline development and testing on z/OS, making it easier for newer z/OS system programmers to tackle operations and automate their infrastructure.

Let’s jump right into a scenario: you’re a z/OS systems tester who wants to display the current status of OMVS to check on its health. The traditional method of issuing this command would be to open up a 3270 emulator i.e. a “green screen”, log onto a z/OS system via TSO, open SDSF, tab over to the command line and enter ‘D OMVS’, which will return the output. Oh — and this is what you’re working with:

A constrained window with a ‘graphical’ interface, with limited space for copy and pasting, and no immediate options to return parseable text formatted in JSON or YAML.

Interacting with the green screen is expected for most z/OS tasks. I highly advise system programmers to familiarize themselves with 3270 interfaces such as TSO, ISPF, and SDSF and how to navigate and operate with z/OS with it. They are highly reliable thanks to decades of development, are required for numerous mission critical tasks, and sustain a retro charm.

However, interacting solely via a “green screen” limits the extent with which one can integrate the capabilities of z/OS with modern automation and tooling. Languages like Python and CI/CD tools like Jenkins can work beautifully with z/OS — but it requires thinking outside of the beige box, and exploring more ‘open’ alternatives.

This is where Z Open Automation Utilities comes in, offering a suite of binaries that perform z/OS functions within z/OS Unix System Services — meaning they can be executed from an SSH session within your terminal emulator of choice. And to our luck — ZOAU ships with opercmd , which does as it says on the tin:

ssh testuser@ABC
testuser@ABC > opercmd 'D OMVS'
testuser@ABC&opercmd 'D OMVS'
ABC        2026212  16:29:37.00             ISF031I CONSOLE TEST0000 ACTIVATED
ABC        2026212  16:29:37.00            -D OMVS
ABC        2026212  16:29:37.00             BPXO042I 16.29.37 DISPLAY OMVS 482
                                           OMVS     0012 ACTIVE             OMVS=(00)

If the output is still a little unfriendly for one’s tastes, no matter, simply add the -j flag to spit it out in .json

testuser@ABC > opercmd -j 'D OMVS'
{"data":{"output":"BPXO042I 16.32.23 DISPLAY OMVS 617\nOMVS     0012 ACTIVE             OMVS=(00)\n"},"timestamp":"2026212  16:32:23.00","timeout":100,"command":"D OMVS","program":"opercmd","options":"-j ","rc":"0"}

Excellent. Not only does this give us the output of the command, but it feeds back the return code, timestamp, and the original command we submitted — all packaged in neat JSON.

Now one can envision crafting more elaborate pieces of automation — perhaps a Python script that SSH’s into a mainframe, submits opercmdcommands to run health checks, parses the return output and prints them to a GitHub log, or a JavaScript server that continuously checks for DASD volume status and displays it on a webpage.

But with our capabilities boosted, why not dream bigger? Can we use bash for a more streamlined terminal experience? Execute curl to post the output of ZOAU commands to a web server? Pipe in jq to transform the json we’ve just received? But a quick search reveals these tools are either non-existent in a standard z/OS installation, or are scattered as convoluted installation packages from third parties.

Enter z/OS Open Tools: an initiative to port highly useful open-source tools to z/OS, primarily for use in z/OS Unix System Services. The above tools are all ported, alongside neovim , ncurses , nano , and more than 200 other programs.

A quick example of what can be done with jq , which is a command-line JSON processor:

testuser@ABC> opercmd -j 'D OMVS' | jq
{
  "data": {
    "output": "BPXO042I 16.51.59 DISPLAY OMVS 785\nOMVS     0012 ACTIVE             OMVS=(ST,R5,MM,Z2)\n"
  },
  "timestamp": "2026212  16:51:59.00",
  "timeout": 100,
  "command": "D OMVS",
  "program": "opercmd",
  "options": "-j ",
  "rc": "0"
}

The | operator ‘pipes’ the output of opercmd into jq, so jq is reading the JSON that opercmd generates and is pretty-printing it for us. But jq is more powerful than simply rendering aesthetically pleasing text — for example, we can get a leaner output from the JSON and just retrieve the result of the operator command:

testuser@ABC> opercmd -j 'D OMVS' | jq .data.output
"BPXO042I 16.54.07 DISPLAY OMVS 845\nOMVS     0012 ACTIVE             OMVS=(AB,CD)\n"

Very clean.

Let us dive into a more complex example-what if I was embarking on a Pokedex project to catalog all the world’s portable creatures, and wished to record their traits in z/OS data sets — for I’m sure there are still mainframes in the fantasy world of Pokemon.

We can issue a curlGET request to PokéAPI (pokeapi.co) and pass in ‘Pikachu’ as our parameter, pipe that output into jq and pass in . to neatly retrieve the data, then write it to a flat text file titled pikachu_entry .

curl --request GET --url https://pokeapi.co/api/v2/pokemon/pikachu | 
jq . >> pikachu_entry

We can quickly check that the new file pikachu_entry has captured the requested data by using head to get the first 10 lines of the file and wc to check the word count:

testuser@ABC > head -n 10 pikachu_entry
{
  "abilities": [
    {
      "ability": {
        "name": "static",
        "url": "https://pokeapi.co/api/v2/ability/9/"
      },
      "is_hidden": false,
      "slot": 1
    }, 

testuser@ABC > wc -w pikachu_entry
  20477    pikachu_entry

This looks good — however, we are in the realm of z/OS, so we’re not satisfied with just a flat text file- we’ve gotta wrangle with data sets. Let’s use the ZOAU decho command to write to a data set, without the need for using ISPF based editors:

cat pikachu_entry | decho TESTUSER.PIKACHU.ENTRY

decho accepts input from stdin , which means we can pipe in the output of cat pikachu_entry into decho and it will correctly parse it as input. This prevents us from needing to wrap the entirety of Pikachu’s entry between quotes — especially useful when dealing with large text content.

We can confirm that our data set was successfully created and filled in by logging into a TSO session, starting ISPF and querying for our data set name TESTUSER.PIKACHU.ENTRY — we should be able to browse it.

  Menu  Options  View  Utilities  Compilers  Help                              
────────────────────────────────────────────────────────────────────────────── 
DSLIST - Data Sets Matching TESTUSER.PIKACHU.ENTRY          Data Set - Browsed 
                                                                               
Command - Enter "/" to select action                  Message           Volume 
-------------------------------------------------------------------------------
         TESTUSER.PIKACHU.ENTRY                       Browsed           ABC123 
***************************** End of Data Set list ****************************
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
Command ===>                                                  Scroll ===> PAGE 
 F1=Help    F2=Split   F3=Exit    F5=Rfind   F7=Up      F8=Down    F9=Swap     
F10=Left   F11=Right  F12=Cancel                                               

   Menu  Utilities  Compilers  Help                                             
 ───────────────────────────────────────────────────────────────────────────────
 BROWSE    TESTUSER.PIKACHU.ENTRY                   Line 0000000000 Col 001 080 
********************************* Top of Data **********************************
{                                                                               
  "abilities": [                                                                
    {                                                                           
      "ability": {                                                              
        "name": "static",                                                       
        "url": "https://pokeapi.co/api/v2/ability/9/"                           
      },                                                                        
      "is_hidden": false,                                                       
      "slot": 1                                                                 
    },                                                                          
    {                                                                           
      "ability": {                                                              
        "name": "lightning-rod",                                                
        "url": "https://pokeapi.co/api/v2/ability/31/"                          
      },                                                                        
      "is_hidden": true,                                                        
      "slot": 3                                                                 
 Command ===>                                                  Scroll ===> PAGE 
  F1=Help    F2=Split   F3=Exit    F5=Rfind   F7=Up      F8=Down    F9=Swap     
 F10=Left   F11=Right  F12=Cancel

Even with our convenient suite of ZOAU commands, it is reassuring to see the 3270 terminal reflect the new operations we’ve performed.

Now we have a z/OS sequential data set with information about Pikachu, that we are free to do with as we wish. With it being a z/OS data set, one can feed it into jobs that run z/OS programs like SORT and IDCAMS to manipulate and copy data. And with the data formatted as JSON, we can reliably parse it, for example:

testuser@ABC> dcat TESTUSER.PIKACHU.ENTRY | jq 'keys'
[
  "abilities",
  "base_experience",
  "cries",
  "forms",
  "game_indices",
  "height",
  "held_items",
  "id",
  "is_default",
  "location_area_encounters",
  "moves",
  "name",
  "order",
  "past_abilities",
  "past_types",
  "species",
  "sprites",
  "stats",
  "types",
  "weight"
]

That’s right — we can feed the z/OS data set itself into jq . We now have all the keys in the Pikachu data model, so let’s pull some information from the abilities key:

testuser@ABC> dcat TESTUSER.PIKACHU.ENTRY | jq .abilities[].ability.name 
"static"
"lightning-rod"

The ZOAU command dcat will print the contents of the data set, then we use jq to filter that output by iterating over the abilities array and printing the name of each ability, which gives us a clean way of retrieving Pikachu’s innate gifts of Static and Lightning Rod.

jq gives us some powerful formatting tools, for example, we can dig into the stats key, pull out Pikachu’s numerical attributes, and format them as a table:

testuser@ABC> dcat TESTUSER.PIKACHU.ENTRY | jq -r '.stats[] | "\(.stat.name)\t\(.base_stat)"'
hp 35
attack 55
defense 40
special-attack 50
special-defense 50
speed 90

Sometimes, we may want to be extra careful ensure the data is intact when copying it to a data set, as encoding issues may occur. We can create sequential data sets on the fly with dtouch -tseq TESTUSER.PIKACHU.STATS and edit it in ISPF:

  File  Edit  Edit_Settings  Menu  Utilities  Compilers  Test  Help            
───────────────────────────────────────────────────────────────────────────────
EDIT       TESTUSER.PIKACHU.STATS                               Data set saved 
****** ***************************** Top of Data ******************************
==MSG> -Warning- The UNDO command is not available until you change            
==MSG>           your edit profile using the command RECOVERY ON.              
000001 hp              35                                                      
000002 attack          55                                                      
000003 defense         40                                                      
000004 special-attack  50                                                      
000005 defense-defense 50                                                      
000006 speed           90                                                      
****** **************************** Bottom of Data ****************************
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
Command ===>                                                  Scroll ===> PAGE 

You may have noticed I’ve formatted the data in a particular way — this is to prepare it for z/OS’s SORT program! Let’s say we want to sort Pikachu’s stats from best to worst, we can now pass in this data set to SORT — and thanks to ZOAU, we will not need to submit a job. Instead, this can be handled all in one command line input:

echo "   SORT FIELDS=(17,2,ZD,D)" | mvscmd --pgm=sort 
                                           --sysout=* 
                                           --sortin=TESTUSER.PIKACHU.STATS 
                                           --sortout=TESTUSER.PIKACHU.STATS 
                                           --sysin=stdin

ZOAU’s mvscmd program allows us to run the usual programs one may invoke in JCL, but run via z/OS Unix System Services instead, allowing us to convert JCL syntax to single line runnable programs that will immediately provide output.

In this instance, we invoke the SORT program via pgm=sort , then pass in the IBMUSER.PIKACHU.STATS data set as both sortin and sortout data definition statements to indicate that we want to sort this particular data set ‘in-place’. We pass in “ SORT FIELDS=(17,2,ZD,D)” as the argument to SORT , specifying that the value we want to sort by (Pikachu’s statistic) starts on the 17th column, is 2 characters lone, is a zoned decimal (ZD), and presented in descending order.

After running this command in our Unix shell, we can retrieve the output of the modified data set, and verify that it has correctly sorted its stats from best to worst:

testuser@ABC> dcat TESTUSER.PIKACHU.STATS
speed           90
attack          55
defense-defense 50
special-attack  50
defense         40
hp              35

To sum up — using binaries provided by Z Open Tools, we were able to pull data from a live API via curl and clean it up with jq . Then with the commands provided by ZOAU including decho, dtouch , and mvscmdare able to copy to and manipulate data sets to perform operations on this collected data — and we are capable of doing all of this within the comfortable confines of the Unix shell.

The proliferation of modernization efforts on z/OS have transformed it into a more open platform. ‘Open’, in this instance, is no buzzword.

Our capacity to execute tasks on z/OS has literally opened up, with fresh toolkits that integrate more beautifully and seamlessly with modern development environments and sensibilities. There has been an increased push for open-source on z/OS, with a vibrant community eager to share examples of how to leverage this new software to automate legacy tasks. And most important of all, we can approach development, testing, and maintenance of z/OS with more open minds that are receptive to new ways of interacting with these fascinating machines.

Let us continue this culture of openness, of community, and of progress.

Now go and be the very best, like no one ever was.

Open Zesame: Dual Development with Z Open Automation Utilities and z/OS Open Tools was originally published in Theropod on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s take a step back, and recall our motivation for load testing on mainframes from my previous article: we want to hammer our system with a simulated quantity of user activity so we can identify bugs and performance issues before they reach clients. To load test z/OS specifically, I deployed an API load test tool to send requests to a web server hosted on a mainframe, with each request instructing the system to execute some operation such as filesystem read-writes or batch processing. Let’s refer to the machine sending the requests as the ‘control’ node, and the machine processing requests as the ‘managed’ node. For example, a separate Linux instance is a control node submitting POST requests to a managed node in the form of a z/OS partition. The control node must have appropriate network and connection authorizations to communicate with our z/OS test system.

Out of multiple open-source load test tools, I opted for Locust due to its ease of use and familiar Python syntax. This made scripting and executing tests more expedient and accessible, but it presented two downsides:

1. Non-native: Locust does not run natively on z/OS. Even though z/OS supports Python and several of its libraries, Locust’s dependencies present low-level incompatibilities when dealing with how other Unix systems and z/OS Unix handle C calls — I know, as I’ve attempted to install Locust on z/OS and have only gotten so far.
   This means that Locust must run and submit requests from a separate OS running on an external control node. This results in both the control and managed nodes being stressed — even if the intention is only to stress the managed node — and the control node has to be kept active for the duration of the test. This is rather inconvenient for those moments when I want to shut off my work laptop, or when I want to save resources and not leave a Linux VM running overnight.
   While there may be a path to running Locust on z/OS natively, it may be more expedient to opt for a different tool with a higher chance of compatibility.
2. Performance: Locust is written in Python which is a high-level interpreted language. The Python interpreter will run through the script line-by-line as it executes it, as opposed to a compiled program which would be converted into machine code and therefore be more likely to perform faster.
   Locust does offer distributed load generation features for scaling its tests, which could help accommodate the throughput of a mainframe. But this introduces more complexity when scripting these tests and selecting multiple control nodes — and as I say in point 1, it may be faster to just pick an alternative with better performance out-of-the-box.

These two factors may impact one another. For example, a load test being executed on my work laptop may be bottlenecked by its CPU and memory, impacting the efficacy of the test since not all responses may be received in time to validate.

While Locust remains viable, I desired further optimization— a tool I could kick off on z/OS itself, and leave running 24/7. I wanted the mainframe to be both the control and managed node, handling all of the load. I also wanted it to be portable — a binary I could copy from partition to partition without recompiling or interpreting. One such tool fulfilled all of my requirements: Grafana k6.

Grafana k6 is the Go equivalent to Locust. It provides a command line interface with numerous options to parameterize testing, and parses test scenarios written in JavaScript to load test servers via API operations. It is written in Go, immediately solving the two issues presented above.

Well, almost. Go is indeed a compiled language known for its speed, and others have even measured direct comparisons between k6 and Locust, favoring the former. Native z/OS compatibility, on the other hand, is not a given. While z/OS now supports Go, and IBM even documents a process for porting programs to it, k6 is already a mature tool with a large codebase, and porting may not be as simple as modifying a Makefile. However, as I’ve alluded to before, Go being compiled to machine code may increase the chances of native compatibility, so long as we tell the compiler “hey — we’re running on z/OS”. In addition, the promise of being able to compile k6 just once and reusing that binary is enticing.

Porting a piece of software from one architecture to another is a daunting premise, especially with z/OS in the picture. While z/OS’s flavor of Unix — called Unix System Services- offers a lot of support for Unix software system calls, it is still not “just another ‘nix” like Arch or Debian, and there still remain unsupported features and encoding distinctions. Porting may not necessitate a lot of writing new code, but it does mandate a lot of trial and error with debugging, catching compiler errors, digging deep into configuration files and maintaining patience.

Well, as they say, we’ll cross that bridge when we get there. And it’s a winding bridge indeed, requiring us to grok the the recursive process of porting Go software to z/OS:

1. Before porting a package, port its dependencies
2. For each dependency, follow (1)
3. Repeat (2) until all desired packages are compiled

But we won’t know which packages are incompatible ’til we dive in headfirst. To start, I forked the k6 repository, then cloned it to a z/OS test machine. Our goal is a successful execution of go install for k6 — this command will compile the binary, move it to a predetermined $GOPATH/bin , and cache packages for future compilations.

I kicked off a go install within the k6 directory and awaited the oncoming storm of errors. Immediately it complained about an undefined syscall from the afero library, which is a filesystem framework and a dependency of k6.

 # github.com/spf13/afero
../go/pkg/mod/github.com/spf13/afero@v1.6.0/const_win_unix.go:26:15: 
undefined: syscall.EBADFD

As expected — before porting k6, we must port its dependencies. For addressing this undefined syscall, IBM’s docs suggest:

Look for files with build tags like ‘+build linux’ or ‘+build !linux’, which might need to add zos to the build tag: “+build linux zos” or “+build !linux,!zos”.

So I fork and clone the afero repository, added build flags for z/OS:

// afero/const_bsds.go

// Before
// +build aix darwin openbsd freebsd netbsd dragonfly 

// After
// +build aix darwin openbsd freebsd netbsd dragonfly zos

then compiled afero first to ensure the compiler accepts these changes. For example:

❯ cd afero
❯ go install
❯

No errors. It compiled. Whoa.

We’re not done. Next, I had to editgo.modin the k6 repository. This file defines the modules that serve as dependencies for k6. When we compile k6, Go will also compile all the dependencies listed in go.mod, which is why we needed to validate that afero builds properly on z/OS first. We can quickly edit go.mod with the following

go mod edit -replace github.com/spf13/afero => /u/adam/afero

Now when we build k6, instead of pulling the afero dependency from the official repository, it will use our local version. Note that if the original module is already compatible with z/OS, this isn’t necessary.

We’ll try installing again. First, go mod vendor to sync the changes from go.mod , then go install.

❯ go mod vendor
go: downloading github.com/sirupsen/logrus v1.9.0
go: downloading github.com/stretchr/testify v1.8.0
[...]
go: downloading github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369
bash-4.3# go install
# go.k6.io/k6/cmd
cmd/ui.go:322:12: undefined: getWinchSignal

There’s yet another complaint regarding an undefined signal getWinchSignal . This time the call is coming from inside the house! Or more specifically— from the cmd module included in the k6 repository.

I’m not familiar with getWinchSignal , but digging into the source code for ui.go in k6 shows its relation to os.signal , which is connected to how Go handles Unix signals.

if sig := getWinchSignal(); sig != nil {
          winch = make(chan os.Signal, 10)
          gs.signalNotify(winch, sig)
          defer gs.signalStop(winch)
      }

Since this code is related to Unix-specific features, I am inclined to add another z/OS build flag just as we did for afero:

// cmd/ui_unix.go

// Before
//go:build darwin || dragonfly || freebsd || linux || netbsd || openbsd

// After
//go:build darwin || dragonfly || freebsd || linux || netbsd || openbsd || zos

Since cmd is not an external module defined in go.mod , we can move onto running go install for k6 itself. Depending on what modules are already installed, one may need to execute additional downloads, for example:

❯ go mod download cloud.google.com/go/storage
❯ go mod vendor

After submitting these commands, we enter one last go install — and after a nail-biting eternity-spanning minute of waiting for the compiler to end its churning, there in the bin folder of GOPATH was our binary, neatly wrapped up and ready for us to use.

❯ go install
❯ ls $GOPATH/bin
k6
❯ $GOPATH/bin/k6

          /\      |‾‾| /‾‾/   /‾‾/
     /\  /  \     |  |/  /   /  /
    /  \/    \    |     (   /   ‾‾\
   /          \   |  |\  \ |  (‾)  |
  / __________ \  |__| \__\ \_____/ .io

Usage:
  k6 [command]

Available Commands:
  archive     Create an archive
  cloud       Run a test on the cloud
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  inspect     Inspect a script or archive
  login       Authenticate with a service
  pause       Pause a running test
  resume      Resume a paused test
  run         Start a load test
  scale       Scale a running test
  stats       Show test metrics
  status      Show test status
  version     Show application version

Flags:
  -a, --address string      address for the REST API server 
  -c, --config string       JSON config file
  -h, --help                help for k6
      --log-format string   log output format
      --log-output string   change the output for k6 logs, possible values are stderr,stdout,none,loki[=host:port],file[=./path.fileformat] (default "stderr")
      --no-color            disable colored output
  -q, --quiet               disable progress updates
  -v, --verbose             enable verbose logging

Use "k6 [command] --help" for more information about a command.

Voila.

The above porting process is a compact recollection of my experience bringing k6 to z/OS. There were numerous other prerequisite hurdles — quirky Go installation paths, repository encodings, space requirements and so on—that are less relevant to porting Go programs to z/OS and more about growing pains that come with working with newer languages on z/OS Unix System Services.

Regardless of the challenges, once you’ve ported one piece of software, you’ve already grown accustomed to the necessary steps (build, fix, sync, repeat) to port other programs.

As for the above changes to afero and k6 — I’ve already opened the respective pull requests for both so that those changes may be rolled upstream.

Go support on z/OS opens up a plethora of opportunities for bringing popular, performant, and practical utilities to the platform. With an easily documented sequence of steps, I was able to compile a well-known cloud testing tool and deploy it in our own test environments, while fully leveraging the existing documentation and resources. It felt empowering and enjoyable working with and contributing to open-source software in the context of mainframes.

I am eager to delve more in-depth about our advanced usage of k6 in z/OS testing, but for now, we can cherish our Go-rgeous victory.

Go-ing Native: Porting Grafana k6 to z/OS with Go was originally published in Theropod on Medium, where people are continuing the conversation by highlighting and responding to this story.

A 20th Century paradise, built from the ground up, sustained entirely by an overwhelmingly Black American population.

This ‘Black Wall Street’ was packed with business centers, hotels, cafes, shopping malls, high-performing schools and homes featuring modern conveniences.

You probably never heard of this place, the suburban community of Greenwood in Tulsa, Oklahoma. It may not have been in any history textbook you’ve read, or Netflix documentary you watched at 3 in the morning. It might not have even been brought up during Black History Month, despite all the lip service paid to figures like MLK Jr. and Malcolm X.

A thriving, technologically superior black neighborhood. Empowering and inspirational, especially considering the rhetoric spat out by politicians and media figures concerning the black community, even today.

As a South Asian immigrant, my presence in academic institutions and workplaces communicates the ‘model minority’ narrative to society, that my family and individuals like me are ‘inherently’ capable of uplifting ourselves out of rigid socioeconomic conditions through intellect and grit.

This same narrative is not granted to black Americans, however, who are vilified in the media as being disadvantaged due to their own accord. The renowned “Black Wall Street” says otherwise, but unfortunately, it seems there is great care in wiping it off the record. Just as it had been wiped off the map.

Indeed, on May 31st and June 1st of 1921, members of the white community in Tulsa carried out a vicious attack on ground and from the air on the African-American community. Over 30 blocks of the neighborhood were demolished by airstrikes and bombs, 300 black people were killed, 800 admitted to hospitals, and over 6,000 were detained.

For the black veterans of WWI, they would have been reliving the horrors of combat in their own neighborhood. Dynamite, turpentine bombs, machine guns, gas…. all were being deployed by American citizen unto American citizen. Later investigations showed the city of Tulsa to have conspired with the white mob, hence why no fire alarms sounded and why police joined in, firing machine guns into the black crowd. A travesty.

The former success of Greenwood and the massacre’s events were given no mention in town, city or state histories. Although it had been initiated after armed black citizens were attempting to prevent a lynching at the police station, historical records at the time shifted the blame towards the black population for ‘instigating the riot’.

Such was the story of Greenwood and its accompanying massacre, unheard of for almost eight decades until 1996 when the state legislature established the Tulsa Race Riot Commission to gather survivors’ anecdotes, collect more information and correct the historical record. They even recommended reparations to the survivors’ descendants.

Still, this event is not taught enough and its history must be proliferated. Students and society in general need to understand this one instance of black American brilliance, and how swiftly it was taken away as white citizens and the State conspired acts of domestic terrorism.

African-Americans and their allies must keep the memory of Black Wall Street in their hearts, for the goal of the Black Lives Matter movement and Civil Rights in general is to remove the notion that ‘Black’ and ‘Wall Street’ do not belong in the same sentence.

That the principles of hard work and self-sufficiency definitely do apply to black communities. That the state has taken an active hand in preventing the upward mobility of these communities by reinforcing systems of segregation through economic policy and mass incarceration.

So when politicians and media figures stand up at the podium and talk down to Black Americans while burning the image of devastated and violent black communities into the collective unconscious, we know better. We must engage in collective remembrance and retell the story of the minority experience in America. Do not forget.

But what are we swarming, and why? The ‘what’ is an IBM Z mainframe running z/OS. The ‘why’ requires a bit more explanation.

Mainframes necessitate large-scale transaction processing. They must handle the millions upon millions of daily requests and responses that power the financial, manufacturing, transportation industries, among others. This means sustaining a large number of concurrent users and transactions per second while ensuring consistent availability. For example, financial institutions have been known to deploy mainframes to support the huge quantity of credit card transactions they need to transmit, process, and store.

As a z/OS Systems Tester, my work on a mainframe OS does not begin and end with validating the input and output of a function. I must verify if such functions can handle the necessary stress that a mainframe workload might induce. As we introduce several new functions to our test systems, we want to regression test these new features to ensure they do not break existing ones, making certain these functions still behave as expected, especially under load.

Simulating load on the system can help preemptively identify bugs and resource shortages. Remember those websites getting hammered with thousands of orders for sneakers or a PS5, and buckling under the load of demand? By testing for these scenarios, including edge-cases where demand suddenly spikes, one can ensure their server stays up and running on D-Day. Consider a load test a rehearsal, with the tester the director — deciding what type of requests are sent, during which times, how often, and what responses to expect.

Having established what a load test is, it’s time to pick a tool from our toolbox. In addition to the custom internal test frameworks we’ve developed over decades, there exist open-source and more ubiquitous tools, such as Apache JMeter, Locust, Gatling, and Grafana k6. These tools are intended to load test web servers that expose REST APIs, and are extensible, enabling us to load test certain z/OS functions provided there is an API endpoint we can submit requests to. These tools present additional advantages to our internal ones, like being able to script testcases in popular languages such as Python and JavaScript, and more seamlessly integrating into our CI/CD pipelines and source control management.

When starting out writing load tests for z/OS, I chose Locust for its more straightforward Python-based syntax. Behavior for each simulated user is specified in a Python script, e.g.

# locustfile.py
from locust import HttpUser

class WebsiteUser(HttpUser):
    def on_start(self):
        self.client.post("/login", {
            "username": "test_user",
            "password": "test_password"
        })

The WebsiteUser performs a simple task — upon initialization, submit a post request to the /login endpoint, with username and password included in the request payload.

Some arguments Locust accepts for its load test parameters include:

• -H — The host Locust will target, in the form of a URL
• -u — The number of simulated users
• -r — Rate at which users spawn per second
• -t — Total duration of the run
• — headless —Execute the test exclusively from the command line, without opening up a web UI

For example, to execute a one hour long test with our WebsiteUser against example.com with 100 simulated users, spawning at 10 users a second and running only the command line, we’d enter the following command.

$ locust -f locustfile.py -H example.com -u 100 -r 10 -t 3600s --headless

Now that we have an understanding of how Locust works, how can we use it to target our mainframes? After all, Locust is intended to target web API endpoints, while z/OS is known for its green screen terminals.

Thankfully, there’s the z/OS Management Facility — z/OSMF. This software provides a framework for executing system tasks via web interface — and it also exposes a REST API for z/OS functions. The z/OSMF server is a task that runs on z/OS, and is able to submit jobs, create data sets, and send console commands.

Table 1 lists two job-related operations a user can perform by submitting GET requests to a specific HTTPS endpoint. Traditionally, submitting a z/OS job (i.e. a task or process that can be run in batch) requires logging on to a 3270 green-screen terminal, but now it can also be automated through REST APIs — therefore making a perfect candidate for user behavior our load test can simulate.

Here’s a snippet of how we can use Locust to submit jobs to z/OS:

test_jobs = ["//TESTSC JOB (),MSGCLASS=H\n// EXEC PGM=IEFBR14", 
             "//TESTSB JOB (),MSGCLASS=H\n// EXEC PGM=BPXBATCH,PARM='sh sleep " + str(random.randint(10,30)) + "'",
             "//TESTSC JOB (),MSGCLASS=H\n// EXEC PGM=BPXBATCH,PARM='sh echo HiFromRest'"]
  
class JobsUser(HttpUser):
    @task
    def on_start(self):
         with self.client.put("zosmf/restjobs/jobs", headers=headers, data=random.choice(test_jobs), catch_response=True, auth=(USERNAME,PASSWORD),verify=False) as response:
             print("Submitted " + response.json()['jobname'] + " with job ID " + response.json()['jobid'] + ". " + response.json()['phase-name'])

First, we define a list of strings representing a test job. The jobs are written in Job Control Language (JCL), a scripting language to specify instructions for z/OS batch jobs, which our system will parse and execute. These sample jobs will either perform nothing, execute shell commands to sleep for a certain period of time, or print text to the z/OS Unix shell.

When a new JobsUser is spawned, it will send a PUT request to the zosmf/restjobs/jobs endpoint, along with the necessary authorization and headers, randomly select a test job from the list, and include that string in its payload.

The z/OSMF server will accept the PUT and read in the JCL from the string passed in by the request, and the result is captured in the response variable. We can retrieve data from that response to check the status of our job and print its output. For example, we can check if our job is in the OUTPUT queue, which confirms our job completed processing, and set a corresponding variable. This lets us validate proper submission, execution, and output for all jobs submitted by each user, confirming that the server is properly handling all the requests when under load.

                  if response.json()['status'] == 'OUTPUT':
                      job_complete = True

Now all the pieces are in place. We have a reliable tool in Locust to create user scripts for our load tests, and we have a server to run our load tests against in the form of z/OSMF. This enables an expansive breadth and depth of testcases, for example, have hundreds of users submitting thousands of jobs over a 24 hour period, or have thousands of users writing to files on the system with 1 user spawning every 2 minutes for two days.

Simulating activity on a mainframe can seem daunting at first, but by leveraging existing open-source tools and the latest z/OS features, we have an accessible, extensible, and effective means of generating load on our servers. We can stamp out the bugs to come, with a swarm of our own.

Special thanks to Frank De Gilio, Michael Gildein, Anthony Giorgio, and Luisa Martinez for assisting in the writing and publication of this article.

Swarming Stressed Servers: Open-Source Load-Testing on z/OS Mainframes with Locust was originally published in Theropod on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is an unmatched clarity to creating art from limitation.

In my Wesleyan junior fall, I seized such an opportunity. I directed the very play that thrust me into the realm of theater.

Ayad Akhatar’s “Disgraced” was first presented to me as an opportunity to leverage my identity as a young Desi male and perform several times as Hussein Malik / Abe Jensen, whose experience mirrors my own (to an extent, thankfully). The Readers’ Theater of Connecticut had reached out to Wesleyan’s Muslim Chaplain and to its Theater Dept. querying for someone who fit the description (a rare moment where, for a man of color, ‘fit the description’ was something undeniably positive).

At that time, I ached to act and probably would have accepted any role. I remember my freshman self dashing to the Office of Religious Life to meet with directors Anne Cassady and Richard Kamins, clearing my throat to try out for the part. No knowledge or preparation of the play beforehand, I was essentially cast because I was one of the first and only people to have responded to their casting call.

Fast forward to two years later; I was handing out sides for the parts I had grown to know almost as people in their own right. In my head, ‘Isaac’, ‘Jory’, ‘Abe’, ‘Emily’, and especially ‘Amir’ were real, and spoke to me, and each of them was the type of person who would be indignant if I botched their casting.

I’d like to say I didn’t! I wouldn’t know, for as I was steeped in weeks of rehearsal, the actors in front of me grew into their roles so well that, as far as I was concerned, they were the characters, just as I had become ‘Abe’ when I embodied him years prior.

It was not a seamless beauty. We were, after all, university students (and in the case of one of my cast, a university employee) for whom top grades and career aspirations were the priority. Second Stage, the production company sponsoring my play, is volunteer-based and entirely student-run, and our entire cast and crew had limited experience in theatrical production.

This was my first time directing, and although professional directing experience was available on Wesleyan’s campus in the form of Directing I, II, and other courses, these were essentially inaccessible to me. I had always seen my theater major as a separate and smaller interest from my career path in software, I had never imagined that I would end up being one of the individuals on campus who would run a theater company, act in major productions, and direct a play.

Seven courses, frequent physical therapy, being the lights liaison of a major production company, and directing a play. And yet, I felt an odd sort of freedom, the kind where I was able to choose my own pain and look forward to seeing this production come together.

Personal and logistic limitations lent the play a unique authenticity, a sense of things being handcrafted and incidental. The stage was not a grand proscenium but an improvised black box in the basement of Wesleyan’s Malcolm X House. The lavish NYC apartment Akhtar describes was framed by pieces of furniture borrowed both from the Center for the Arts, the office of Wesleyan’s theater technical director, and people’s personal possessions. My lack of experience as the lights liaison meant I could barely figure out how to actually bring theatrical lights into the space, so off to Ikea we went to obtain remote controlled lighting peripherals, and off to my room I went to grab my floor lamp.

But, I mean, Jesus. Subhanallah.

I’m still in disbelief at how ragtag the process was and yet how cohesive the final product felt. Our limitations brought out a collective genius, where my team’s experience in film and art translated to selecting the perfect wallpapers, furniture pieces, and props that could coexist in this communally crafted microcosm.

The aesthetic was a vibrant yet classy red, white, and dark shades of navy and black which cohered with the costume design and complemented by geometric patterns; the jazzy sound design provided this with a greater reality, ambience that cast judgment on the characters themselves. The set was flanked on the northeast by a handbuilt balcony setpiece that my set designer Angelica and her volunteer carpenters toiled to make which lent the illusion of an outer world, a clever method of masking the shattered glass prop that Arnaav needed to toss to the floor in a fit of rage.

There not being any theatrical incandescent lighting meant the set needed to be lit entirely by ‘naturals’ — a small table lamp near the ‘fireplace’, a floor lamp from my room, and LED strip lights near the ‘lobby’ — all of which were tethered to wireless light dimmers that needed to be on cue with certain moments. This ended up being a rather cool element; even though audiences were familiar with how theatrical lighting systems were set up with lightboards and specialized software, our system was entirely improvised and home-made and set within the confines of this residential area. The space was truly transformed.

I miss it, of course. I burn with nostalgia at this halcyonic winter, where I was provided both with freedom and restriction to collaborate and create a work of art that adhered so much to personal identity yet was blessed with community. It was a lighting flash, a moment trapped in amber and cast in flame. It could only have happened in my final year of college with this collective of individuals in particular.

I don’t know if I am even a good theatermaker, if I am a decent actor or director, but I know that I enjoyed seeing the final product, and I know that I ache with a desire to do more. Even in the midst of writing this, there is more that I want to say (specifically about why ‘Disgraced’ deserves a Pulitzer, but that is for another time).

A final thank you to all of the individuals mentioned here, my cast and crew, my team. Some of the artists of the future are mentioned in this very program. To them, I give much 💕.

Official publicity photographs courtesy of Elijah Comas ‘22

That adorable directing photo courtesy of my Stage Manager Thanmye Lagudu ‘20.

This article is also featured on my personal website and blog http://adamr.io — check it out. :)

As I leaned against the couch in the lobby, I traced a route in my mind’s eye — from the Dhaka hospital where I was born, to the teensy-weensy lead-chipped apartment my parents and I sidled into when we arrived here in the new millennium, to the finale of my academic career at Wesleyan where I finished up my B.A. in Computer Science and Theater.

“How did I get here?”

This question was fueled by a Matcha-Yerba Mate infusion I had concocted that morning, heated with a silent prayer that the pen-and-paper knowledge gained from my Computer Science courses would translate well to this particular opportunity. My internship was already on its way; just a week after final exams ended that semester, I was installing React packages and running Docker containers to view UNICEF’s MagicBox platform for myself.

MagicBox is an open-source multifaceted collaborative platform for aggregating, ingesting, and understanding the big data corresponding to specific phenomena in UNICEF programme countries, from connectivity to disease outbreaks. Crafting visualizations and developing machine learning models from the data collected can go a long way in predicting and planning for natural disasters, epidemics, or other exogenous factors that may disrupt wellbeing.

I knew quite well about the phenomena faced by developing countries on the other side of the world — whether it be my performative writing seminar where race and class was on everyone’s breath, or my course on social entrepreneurship and philanthropy — Bangladesh and/or its third-world problems were a persistent thread. Having moved to the U.S. so young, I was only familiar with the sensations of my country of origin — the heat and humidity, the fabrics and clear skies — distinct from the powerful and monolithic view of the United Nations towers from the UNICEF innovation office.

There, Mike and my other supervisor, Marcella Maki, helped me discern my route through this internship, which was partly remote and partly onsite. My fellow intern, Courage Angeh, was working remotely from Cameroon, which made for an interesting dynamic as I was often one of two interns present in the UNICEF Innovation offices.

I couldn’t believe how fortunate I was, that I’d be able to look after my family and prepare for my final semester at Wesleyan while transmuting the conceptual into the concrete. These next two months were spent in a deep dive of scientific computing, geospatial analysis, virtual machines, and plenty of tea — of course. In Part II of this piece, I will describe how I tackled healthsite accessibility, the challenges faced, and why it affirmed my desire to code with purpose.