It was 2003 and I was a young Millennial Mainframer completing my post-secondary education in a post dot-com world. Internships were difficult to obtain and it was looking grim starting a career supporting servers and IT miscellaneous when I was told companies were cutting back and not hiring.

By bloody charm and my frickin’ social tact alone…I obtained an interview to work at the Data Centre for the Canadian Government.

I remember the day I was given a tour on the raised floor computer room, shown tape libraries, rows and rows of severs, and finally the mainframes and then told bluntly my real education hadn’t even started yet.

As like most Millennials, technology and IT came easy to me, but the mainframe and specifically the z/OS operating system initially offered a more challenging and very daunting learning curve. Green screens, TSO, ISPF, JES, OPC/E (now TWS), NVAS, JCL, master consoles, backup consoles, tape drives, Parallel Sysplex…

It truly was a new universe to learn and discover.

After a few months of getting mentored and job shadowing some of the other Operators, I began overseeing some of the facilities myself during off hours. It was during this time that my education with the z/OS operating system really began to suffer as the only time I learned was during breakages and any systems ABENDS. The downtime and instability for z/OS was next to nil.

To combat knowledge fatigue and ensure knowledge transfer I relied on the proactive fail-safe… pestering the more experienced on-day staff with a cornucopia of questions.

Slowly the tips and tricks were passed on to me.

Little local libraries of documentation started to grow.

And my own personal “Captain’s Log” entries became my digital bread crumbs back to solving all re-occurring problems.

When I was transferred as on from Operations into System Programming, I continued using the same tactics as I use today. Thankfully IBM has extensive resources I exhaust before I go “pestering tsunami” on my colleagues.

The IBM z/OS Internet library ( is always a good place to start.

Redbooks ( have the ABCs of z/OS System Programming, and the must-have biblical “Introduction to the New Mainframe z/OS Basics” for glossary of IBM acronyms.

And finally after all the research and efforts on my end have been attempted, opening a Service Request with IBM ( usually resolves the problem.

I always make sure the solution is captured in my notes, personally I enjoy using something simple like my own personal Wiki (

As I continue to down this career path with mainframes I’m always glad to meet fellow Millennials, as this journey can sometimes be a lonely one. That being said, connecting and learning from those close to retirement are also vital. Concepts second-nature to them can take us years. Be ready to flatter your older colleagues to get them talking, and make sure you’re taking notes in order to squirrel away any knowledge they share.

“That’s a sharp tie you’re wearing there Ron!”

Paul Gamble
Graduate of Georgian College, Computer Programmer Analyst program

After doing a four month internship with the Canadian Government, Paul was offered the rare opportunity to work in their on-site Data Centre. Starting out as an Operator for four years before becoming a Systems Programmer rolling out different independent software vendors (ISVs) and different IBM Tivoli products for monitoring and automation to the z/OS platform. Paul enjoys the constant learning the z/OS operating system offers in comparison to other platforms. On weekends you’ll find Paul getting his adrenalin fix by instructing and coaching at the local skydiving drop-zone.
Connect with Paul on LinkedIn

4 thoughts on “How I Started with Dinosaurs? – A Millennial Mainframer Saga

  1. Hi Riya,

    Those are some real interesting facts. Was wondering if you knew any large DB2 shops that run their web sites on the public cloud, e.g. Amazon Web Services (AWS), and access their DB2 installation (running on Z/OS) within their own Data Center? Seems like one could do it through AWS using AWS Direct connect.


  2. @henri-kuiper, I think that you’re right that people often look for a technological big fix to solve underlying social/organizational/cultural problems because directly confronting those underlying problems requires change, and change is stressful and hard. That said, once any organization has come to the conclusion that they need to change from the status quo, they then need to decide what they want to change to. This decision often creates winners and losers, and ends up being inherently political.

    I would see this all the time as a mainframe architect. Let’s say that a business depends on a mainframe application from the 1970s built around IMS, and there is general consensus that the application needs to be “modernized” to increase agility. Some may argue to modify the code to leverage new features integrated into the latest versions of IMS. Some may argue to move to DB2 for z/OS for a more flexible data model. Some may argue to move the application to Linux under z/VM to exploit open-source packages and ubiquitous Linux skills. Some may argue to replace the application with a commercial off-the-shelf Windows Server app or a SaaS app delivered through a browser.

    So I guess that I would word your statement that “change is good” a bit differently. Change in and of itself seems value-neutral to me, so I would instead say “Openness to Change is Good.” Ideally, an organization would need a way to hash out the political conflicts inherent in change, including ameliorating the losers, keeping the winners from getting too cocky, and maintaining diversity opinion to always ensure that there is someone out there asking, “Can we do this better/cheaper/faster?”


Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>