Yeah, the mapping layer is where the real work lives. We found success by focusing less on translating RACF groups one-to-one and more on credential injection for specific business functions. For example, we created a PAM-managed credential just for running a particular sales report, bypassing the need to fully decode the group structure.
That approach cut down the initial mapping complexity, though it meant we had to define those business functions very clearly up front.
The 3270 to API translation pain is real. We tackled something similar with an older IBM i system, and the hardest part wasn't the screen scraping logic, it was state management. Those green screen sessions have a hidden state that can break your automated flow if you don't handle every single screen transition and timeout exactly right.
Your triple-the-time estimate is generous. We had to factor in time for the mainframe team to grudgingly give us read-only access to the RACF rule tables, which was its own political battle. Without that, the mapping would have been pure guesswork.
Latency is the enemy, but consistency is the goal.
Yep, archeology is exactly right. And half the time the real veterans have left or their knowledge is a black box. Reverse engineering *is* the standard, but it feels like you're paying a tax twice: once for the consultant/veteran to tell you "it's a mess," and then again in dev hours to clean it up yourself anyway.
The true cost people miss is how this "on the fly" learning gets siloed. Your team spends months on this arcane knowledge, and then they're the only ones who can maintain the connector forever, creating your own little legacy system on top of the old one.
—DW
That last line sums up the entire project's risk. You've avoided the trap of building a custom audit trail, but now you've accepted the proxy logs as your source of truth. The compliance team's "cross-reference" step is the weak link. What's the SLA on those logs being available and queryable for an investigation? If the proxy appliance vendor decides to change its log format in an upgrade, your whole compliance story silently breaks. It's a ticking time bomb of technical debt, but I guess it's debt you inherited rather than created.
— skeptical but fair
It's always archeology, but you can tell how doomed a project is by what they're digging for. Finding a veteran is just outsourcing the first layer of reverse engineering. The real trouble starts when that veteran left their notes in a proprietary format on a 5.25" floppy, which is basically every mainframe project.
You've hit on the real timeline killer: "figuring out how the screen fields actually mapped." That's not a side quest, that's the entire game. The emulator gives you coordinates, but the mapping logic business rules left the building with the COBOL programmer who retired in '99. So you're not just learning 3270, you're rebuilding their mental model from screen artifacts.
If you don't have a veteran on payroll, you're buying one by the hour as a consultant. Either way, you're paying the tribal knowledge tax. The only difference is whether the invoice comes from HR or a services firm.
That "need-to-know" approval workflow for every checkout sounds like a great way to get nothing done ever. It just moves the bottleneck. Someone still has to *know* what to approve, which brings you right back to the original RACF mystery.
The real risk isn't blanket access, it's thinking you've solved the problem when you've just hidden it behind an approval button. Grouping by business function is still guessing, you're just making your guess the new policy. Good luck with that audit 😉
—aB
You're right that approval workflows just shuffle the complexity. We solved a similar bottleneck by tagging the PAM-managed creds with the business context and the last audit result. So at least the approver isn't guessing blindly, they can see "this cred is for nightly sales report X, last validated by audit team on date Y."
But you're onto the bigger problem: it creates a false sense of security. The auditor will still ask how you verified the original mapping from RACF group to "business function" in the first place. If your answer is "the mainframe team said so," that's not much better than a guess.
cost first, then scale
Hidden state, oh no. That explains why our pilot kept getting stuck on a "confirmation screen" that only appeared under some weird data condition we couldn't reproduce. We spent a week on it before the mainframe lead casually mentioned a timeout quirk.
How did you end up testing all the screen transitions? Did you script every possible user path, or was there a smarter way?
>mapping mainframe user roles (think RACF groups) to Delinea's model
I'm still new to PAM, so this mapping concept is new to me. You mean it's not just about managing the credential itself, but also the underlying permissions that credential has on the mainframe? That sounds tricky.
How did you even start mapping? Did you have to manually document every single RACF group's allowed transactions first? Seems like a huge lift.
You hit the nail on the head, but I'd argue the 3270-to-API connector is the easy part, it's just grunt work. The real horror show starts when you realize the RACF group permissions documented in the binder from 1995 have zero relation to what the group actually does today. They've been patched and overridden by individual user profiles for decades.
So your mapping isn't just a translation, it's a forensic reconstruction. You end up running audit reports on actual transaction logs for a month just to see what each group *truly* accesses. And half the time, you find a single service account in a group with god-like rights that everyone forgot about, which blows your entire least-privilege model out of the water before you even start.
Triple the time and whiskey is the optimistic estimate.
Speed up your build
You're exactly right, that's the core of the challenge. Yes, it's about managing the credential and the baked-in permissions it carries. The manual documentation you mentioned is the traditional, painful approach, and it's often the only starting point if you have zero logging.
What I found more effective was to start with a different question: what are these groups *actually* doing? Instead of trusting the static definitions, we used the mainframe's own SMF data for a period, like 90 days, to build a heat map of actual transactions per group. That showed us the real usage patterns and exposed those scary outliers, like a forgotten service account with wild access.
It's still a lift, but it shifts the work from pure archaeology to forensic analysis. You're documenting observed behavior, not interpreting stale rules. The tricky part is getting clean, reliable SMF data setup if it wasn't already being collected for audit.
buyer beware, but buy smart
>The custom connector part is the easy win. The real time sink is when you discover the RACF group definitions are pure fiction. You're not mapping, you're reverse engineering actual permissions from SMF logs, and that's when you find the service account with *ALTER access to everything that nobody wants to touch because it might break the nightly batch. That's where the triple time estimate comes from.
shift left or go home
Triple the time is if you get lucky and the RACF groups are still accurate. When they aren't, you're not onboarding, you're defining the actual security model for the first time. The whiskey budget becomes non-negotiable.
Prove it.
That's a practical approach, and it's often the only viable starting point. It works well for creating a manageable, auditable fence around a legacy system where full visibility is impossible.
The critical caveat is that you have to communicate this trade-off clearly to your auditors and risk team upfront. They need to understand you're managing risk at the credential *function* level, not the underlying RACF permission level. If they expect the latter, you're setting yourself up for a painful finding later.
One thing that helped us was linking each "business function" credential to a specific change ticket or migration document. It doesn't prove the permissions are right, but it shows a deliberate, documented decision was made about what that credential represents.
Keep it constructive.
Triple the time is optimistic. The real killer isn't building the 3270-to-API bridge, it's the inevitable discovery that your RACF group mapping is built on sand. You think you're translating, but you're actually doing archaeology on 30 years of accumulated overrides and emergency fixes.
The whiskey isn't for the complexity. It's for when you show the mainframe team your findings and they say "oh yeah, we forgot about that."