Written by Ashish Kumar Dash, Open Mainframe Project Summer Mentorship 2026, mentee researcher, guided by mentor Francesco Giordano

I started contributing to the Zowe Java Client SDK before anyone told me I was allowed to.

In late April I was scrolling the LFX Mentorship listings and found a project about implementing z/OSMF Workflow APIs in a Java SDK. I had no mainframe background. So instead of writing an application straight away, I cloned the repo and started reading it, on the theory that if I couldn’t understand the codebase, I had no business applying to work on it.

Two days in, I found a bug.

Use inline code formatting:

ZosLog.issueCommand() built its query string by always appending time first, but the optional parameters — timeRange, direction, hardcopy — could still be appended with ? depending on a counter. Combine the right filters and you got a URL like:

.../restconsoles/v1/log?time=2026-04-24T10:00Z?timeRange=10m

Two question marks. Invalid URL. I fixed the delimiter handling, added a regression test, and opened PR #460 with an apologetic note asking whether I should have filed an issue first.

The maintainer, Frank Giordano, replied the same day: “Thank you for this PR. I will review.” The next day he merged it and cut a release. Then he opened two follow-up PRs of his own that took the fix further and reworked URL construction across the whole API, and told me it was going into 7.0 rather than a patch release because the scope had grown.

That was my introduction to how this project works: you find something real, it gets reviewed fast, and the fix often turns out to be bigger and more interesting than the thing you noticed.

What I actually shipped

By the end of the program I’d opened 23 PRs and had 20 merged. The core of it was the z/OSMF Workflow API surface — the thing the mentorship was actually about:

PRWhat it added
#513	Create Workflow API — WorkflowCreate, input/response models, serialization tests
#518	Retrieve Workflow Definition API — plus typed step and variable definition models
#522	Get Workflow Properties API — including polymorphic step parsing via @JsonTypeInfo(DEDUCTION)
#546	createLocal — uploads local workflow files to USS, creates the workflow, cleans up temps
#576	List Workflows API — six optional query filters, enums for fixed-value parameters

Around that, a second track of work that wasn’t on any assignment board:

• Bug fixes — the z/OS log query string (#460), a constructor validating the wrong HTTP request type in ZosmfLogin (#465), TsoReply producing false-positive errors when the string msgData appeared in ordinary message text (#496), and a package literally named reaponse (#486).
• Tests for areas that had none — the zosmfauth login/logout/password flows (#466), USS response mapping (#485), ZosLog pagination (#491).
• Other APIs and cleanup — Delete System Variables (#525), Migrate Datasets (#575), the missing zosvariables package README (#580), and replacing the last non-Jackson JSON code path in src/main (#581).

What the review comments actually taught me

The code I wrote is the least interesting output of this mentorship. The reviews are the part I’ll still be using in five years.

A correct fix to the wrong problem is still the wrong fix

I opened #484 to fix a ? that should have been an & when path and fsname were combined in a USS ZFS query. Frank’s reply reframed the whole thing:

The syntax of combining them is incorrect as you noted, but the combination is in itself wrong and breaks the API. The parameters should never be combined.

Then he read the input class more carefully than I had, found the builder already threw IllegalStateException Zx when you set both, and closed the PR — adding that a factory here “would be overkill for a two-parameter input.” He was right on both counts. I had fixed the formatting of a URL that could never legally be constructed.

The lesson isn’t “check harder.” It’s that when you find a malformed output, the first question is whether that input should have been reachable at all.

Sometimes the right answer is “close this and do it properly”

#479 hardened validation on the USS ACL builder, which allowed too many mutually-exclusive combinations. Frank’s take:

What you proposed is more of a workaround rather than a complete solution. The builder pattern should be replaced with a factory pattern so the end user selects one specific modified identifier, instead of having the builder allow too many open-ended combinations.

I argued the validation was a safe interim fix while the factory refactor got scheduled. He came back and closed it: he wouldn’t ship code he intended to rework anyway, and he asked me to split out the one small piece that stood on its own. That became #480, merged the same day.

Three of my 23 PRs were closed unmerged. Every one of them changed something — the design of a later refactor, my understanding of an API contract, or a teammate’s PR that landed instead. Closed is not rejected.

Consistency with the codebase beats consistency with your own taste

I like named constants for query parameter keys. The project doesn’t. I got told so three times in one review on #518:

I prefer not to use query parameter name constants. The project mostly hard codes these names in the url construction. Let’s do that for consistency.

And again on #576: “These constants are not used more than once so I usually prefer as done in the project to use the hard coded value instead.”

I still like the constants. I also now genuinely believe a codebase where every file follows one convention is worth more than a codebase where every file follows its author’s best convention.

The same review taught me something about attribution that I hadn’t considered:

I prefer to keep the original author here and not add on. The author that originally created the file and added content. Additional authors add themselves to added methods they introduce.

Name things after the API you’re wrapping, not the code you’re writing

My UssSetAcl used targetPath. Frank pointed at the IBM documentation — PUT /zosmf/restfiles/fs/\<file-path-name> — and asked for filePathName, “so it syncs up with the API documentation and makes it more understandable for the end user.”

Same principle, bigger scale: I submitted a class called WorkflowRetrieve. It got renamed to WorkflowGet, along with its input, response, and three test classes, to match the existing JobGet convention. An SDK is a translation layer. If the names don’t line up on both sides, users pay for it.

Test the API, not the parser

On #485 I wrote clean isolated unit tests for JSON mapping of the response POJOs. The feedback:

The most effective way to test the parsing logic is to execute the API call itself and validate the returned response… This approach provides better coverage than testing the parser in isolation, since JsonUtils.parseResponse is already exercised within the API implementation.

He also told me to stop using toy JSON fixtures and paste in the full example document from the IBM docs — the one with nulls, nested arrays, embedded newlines, and a field called abstract. My tidy little fixtures had been passing because they never contained anything difficult.

Use the dependency you already have

Twice. On #525: “Jackson is already a dependency, you should use it instead of org.json.simple.” That stuck with me enough that months later I went looking for the inverse — and found ZosmfStatus was the last file in src/main still parsing JSON with kong.unirest. #581 removed that path, and closed out a loop I’d opened myself.

Deleting your own code counts

#530 removed a getProperties boolean overload I had written a week earlier, because the builder-based common method already covered it and read better at the call site. Smallest PR I opened. One of the ones I’m most pleased with.

About my mentor

Frank Giordano reviewed nearly everything I wrote, usually within a day, often within an hour.

What made him a good mentor was not encouragement. It was specificity. His review comments are things like rename method to deleteAll, or see orEmpty(...), or a four-line snippet showing the exact method signature he wanted. There is no guessing what “looks good but needs work” means. When I got something right, he said so in six words and moved on — “Clever tests. Thanks for the contribution.” — and when I got something wrong, he explained the reasoning rather than just the correction.

Three things he did that I want to remember, in case I ever mentor someone:

He told me when I was out of scope, without telling me to stop. When I asked about taking on the factory refactor, the answer was: it’s outside the mentorship scope, which is workflow APIs — “That said, if you have time, you can still submit the factory refactor changes for review separately. Maybe email me your proposed approach first.” That’s a real boundary and an open door in the same breath.

He merged before it was perfect, for a reason. On #513 he’d left seven review comments, then came back with: “Actually I will merge. It is ready. And this class can be used by the team for testing on a live environment for the other APIs!” My WorkflowCreate became the thing the rest of the cohort used to set up test data for their own APIs. Knowing when unblocking five people beats one more review round is a judgment I didn’t have.

He kept working alongside us, not above us. When I flagged the log query bug he shipped two follow-up PRs finishing the job. When he reworked WorkflowConstants mid-review he told me to merge his changes into my branch and adopt the new pattern. When another mentee’s cancel-workflow PR stalled on a minor change, he made the change himself and merged it. The project kept moving.

But the thing I did not expect, and the thing I’d now call my biggest takeaway, is that none of this stayed inside the codebase.

In July, Frank and I had a long call that was supposed to be about workflow APIs and stopped being about them fairly quickly. We ended up talking about where we’re each from, how work actually looks day to day on either side of the world, what people expect from a career in one culture versus another, and a fair amount of ordinary life in between. He asked about mine with real curiosity, and he answered mine the same way, no performance of seniority, no version of himself he was maintaining for a mentee.

That conversation is what made him a grounded mentor rather than just a sharp reviewer. It’s easy to take blunt feedback from someone once you know there’s a person behind it who is interested in you beyond your commit history. After that call, a comment like “remove your name from here” read as a project convention being explained to a colleague, not a correction being handed down. Nothing about the reviews changed. Everything about how I received them did.

And the cohort mattered for the same reason — @jsamaniego4, @Eshaan-byte, @AditheD, @Muhammad7839, and @Shaurya2k06 took the other Workflow API issues. Different countries, different timezones, wildly different levels of mainframe exposure, all reading the same review comments in parallel, and the API surface came out consistent anyway. My cancel-workflow PR (#571) was built on top of Jorge’s implementation and got closed when his landed instead — which is exactly how it should work.

I applied to this program to learn a Java SDK. I came out of it having also learned how to work with people I’d never have met otherwise, in a culture of review and disagreement and shared ownership that I now want to keep working in. That part grew me more than the code did.

If you’re about to start a mentorship

Contribute before you’re selected. Not to game the application. Because it’s the only way to find out whether you actually enjoy the codebase. I opened seven PRs before the program formally began, and by the time I got my first workflow issue I already knew the project’s conventions, its test patterns, and its maintainer’s review style.

Read the vendor documentation, not just the code. Half the review comments I got were resolved by the IBM API reference. The parameter names, the mutual-exclusion rules, the fact that an empty list is a documented no-op rather than an error — all of it was written down. I just hadn’t read it closely enough.

Push back once, then commit. I disagreed with Frank on the ACL PR and said so. He heard it, explained why he still disagreed, and I dropped it and shipped the smaller fix instead. That exchange took one round trip. Disagreeing productively is a skill; disagreeing repeatedly is a tax on your reviewer.

Fix the things nobody assigned you. Six of my merged PRs were tests and typo fixes and README gaps that no issue existed for. They’re also the ones that taught me the codebase well enough to write the assigned features quickly.

What’s next

The Workflow API surface in the Zowe Java Client SDK is real, tested, and shipping in 7.0. I want to keep going — the factory refactor conversation is still open, and I said early on that I hoped to become a core contributor rather than a mentee who disappears at the end of the term.

Thank you to Frank Giordano, to the Zowe community, and to LFX Mentorship for a program where “go read the code and see what you find” turned out to be a legitimate way in.

 

Stay tuned for more mentee blogs as our Summer Mentorship Program continues!

• Learn more about this year’s summer mentees and mentors
• Watch past mentee presentations on our Mentorship Playlist on YouTube
• Follow our blog for the latest updates from the program
• Connect with us on LinkedIn
• Sign up for our quarterly newsletter