The Unsung Heroes of the Mainframe
The unsung heroes of the mainframe environment are the DBA and Sysprog teams – they understand the technology hoops to jump through, the permissions necessary, the approvals to obtain, the credentials to employ, to support the smooth operation of their domain.
It is worth sparing a thought, though. Their daily task list is equal parts wrestling with technology and internal bureaucracy. Permissions, time-slices, and priorities dictate their activities, and shape their outcomes as much as any technology requirement. And that struggle is real. The 2025 Vanson Bourne Mainframe Market Survey revealed that 88% reported material concerns over the availability of mainframe environments.
Imagine a more efficient means of meeting their requirements while cutting through the white noise of red tape and regulation.
Database Administrators (DBAs)
Fundamentally, the DBA is the gatekeeper of all data. Whether an entire production database, a carefully curated report, a subset of one segment, or implementing an upgrade of the underlying engine, the DBA is the single source of truth of corporate data, and the rules that govern it.
Keeping that ship sailing is an ongoing plethora of regular updates, operational process, reports, requests, all of which consume mainframe time, none of which are – typically – trivial to achieve. Database upgrades may take months, consolidation batch runs take overnight, end of period reports take days.
Time is precious and mainframe resources are very carefully guarded.
Dealing with the endless slew of requests for access to certain data, running ad-hoc reports, out of cycle patches, backups, and recovery, providing database or SQL support or expertise, these are hard to schedule against a backdrop of relentless priority activities. Imagine a situation where such requests could be permitted and enacted in minutes, but without incurring effort or extra LPAR cycles?
In our mainframe scenario we are running at least two levels of COBOL, with a typical setup of a current and a back version of the architecture compiler option. Also typical is that some application teams have already adopted the latest version of Db2, whereas others are yet to do so, and are running one release back. Which means any big changes like a big piece of regulation, or another subsystem upgrade, might have to be checked against not one or two but four combinations.
This normal, simple example, becomes far more complex by considering the other database offerings that the DBAs may to have maintain (e.g. Datacom, IDMS, IMS, Mongo etc). Mainframe users typically run a broad range of data store combinations.
And that is a time consuming, LPAR heavy activity, to administer.
PopUp Mainframe and its FastTrack facility give the DBA their own sandpit to test these things out before anyone or any LPAR time needs to be consumed. This is a hugely productive step forward for routine housekeeping for the DBA.
Keeping the range of environments maintained, tested, and available consumes a lot of resources and disk space. PopUp Mainframe and its FastTrack facility replicate configurations to allow pre-testing by DBAs. Various combinations of — in our example — COBOL and database configurations, that must be checked against a major new application upgrade (or another subsystem being updated), can be achieved without requiring new LPARs or additional Sys Prog effort. With such activities being both commonplace and more complex, the freedom and efficiency this provides the DBA is unprecedented in many mainframe environments.
Systems Programmers (Sysprogs)
Speaking of Sysprog (or Sys Prog, if you prefer) effort – their daily situation is, in the typical mainframe shop, hardly a bed of roses either. They are ordinarily on the hook to set up the “environment” – in whatever form that might take – to enable individuals, teams, and approved 3rd parties to use a correctly configured slice of mainframe time.
And, as was the case for the DBA, this requires curating a bewildering permutation of operating systems, subsystems, data sources (often in conjunction with the DBA), configurations, tools – as well as the right security controls and permissions for the right people.
Again, the conceptual model of having a clean LPAR in which to establish such new environments on an as needed basis overlooks the reality that neither time, skills, machine resources, nor the specifics of the configuration are in ready, abundant supply. The backlog of requests to the Sysprog are as commonplace as the complexities and relative importance of each request.
Sysprogs need a safe space that enables a simple set of steps to set up and store away common configurations that can be handed out as necessary when the requests come in. What they’d really appreciate is a sandpit style environment they can make available, in whatever form it is needed, with the click of a button, to whoever (with the right clearance, of course) requests it.
And the variety of non-production scenarios makes this a common challenge Whether enabling research into a new piece of software, whether researching integration between an application and a new data feed, whether supporting an incubator AI project, whether helping the compliance team meet a deadline with a new environment for testing, or whether testing those technically challenging security changes (new SAF resources, profile or security exit removals, for example) the Sysprog needs to act quickly and safely, but without jeopardizing other requests, or eating into vital, active LPAR slots.
Those scenarios have one thing in common – a z/OS environment, with a specific configuration, that can be built (and, if required, shared) in minutes, using a PopUp Mainframe instance. And once finished, the virtual LPAR can be shut down.
Alongside their DBA counterparts, Sysprogs crave maximum independence and efficiency to support requests immediately, without incurring significant mainframe resource spend. A virtualized environment is ideal for those test cases that Sysprogs must often support, but which need not necessarily consume expensive (and complex) LPAR time to setup and run.
A Modern Approach
For preliminary, research, test, trial, or training activities that require support and resource from the Sysprog and DBA, a faster, more efficient, PopUp Mainframe z/OS environment is available for instantaneous provision, including the user’s choice of technology configuration. Requests for LPAR space can be fulfilled near-immediately because there’s no sharing of the environment, no checks to make, and no wasted resources.
Imagine what a PopUp Mainframe could do for your operational efficiencies. Learn more at www.popup-mainframe.com
