Tips for New Db2 Sysprogs

I’ve been a db2 sysprog for over 20 years.  I have built hundreds of db2 subsystems ranging from stand alone subsystems, adding members to a group, and brand new datasharing groups with up to 20 members.  I have installed maintenance thousands of times across the years and performed version upgrades from v5 through v13.  Chances are, if it can happen in db2 z, I have seen it.  My experience comes from shops large and small mostly in retail and finance.  I’ve been at shops with only one production db2 and at shops with well over 100.

I recently attended a db2 conference for the first time in several years.  I quickly realized that I am no longer the youngest person in the room and am in fact a senior sysprog, no matter how much part of me wants to deny that fact.  While mingling between sessions or at events, I inevitably ran in to newer sysprogs who all seemed to have the same question.  What tips or advice do you have for someone just starting out as a db2 sysprog?  Keep reading for my answer.

1.  RTFM.  Read the friendly manual.  When I started out, the manuals were printed and shipped with your software order.  I had a huge stack of books on my desk.  Now we are lucky in that the manuals are all online and much easier to use.  I cannot think of a single thing I have had to do or fix in my over 20 years that wasn’t well documented in one of the db2 manuals.  You can find all the manuals here:  https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=about-db2-13-documentation
   
   
2. Document everything you do.  Chances are if you have had to figure out how to do something once, you or someone coming in after you, will need to do it again.  Write up your process the first time you do it and save yourself the trouble of having to do all the research a second (or even third) time.  Leaves notes explaining why you chose to do something a certain way.  You and the sysprogs who came after will appreciate knowing the reasoning behind decisions.
   
   
3. Hope for the best, but plan for the worst.  What do I mean by that? Understand what change you are making and know how to back it out.  Always back up what you are changing.  Include return code checking in your JCL.  Validate and test everything you possibly can.  Practice, and streamline, your process in a non-production environment.
   
   
4. Google is your friend.  I’m really not joking when I tell non-mainframe friends and family that 80% of my job is googling things.  Got an error message or return code you don’t recognize?  Google it.  Chances are good that one of the first three links presented will take you to the exact page in the db2 manual you need to answer your question.  Have a question about db2 that you aren’t finding in the manuals? Head over to the Db2 listserv: https://community.idug.org/organization/db2-l/dashboard.  Chances are good that someone else has had the same question previously and has already answered it.
   
   
5. Ask “why?”. A lot.  Why are the zparms set the way they are? Why is the only thing in BP0 the catalog and directory objects? Why do we separate tables and indexes in different bufferpools? 
   
   
6. IBM support is your friend.  Weird dumps and errors messages in the mstr address space? With an IBM id and appropriate support contract, you can open a ticket and get answers and fixes.  You can find support here:  https://www.ibm.com/mysupport/.  Have an idea about how something can be improved?  Open an AHA to get your idea in front of db2 users and developers.  You may do so here:  https://ibm-data-and-ai.ideas.ibm.com/ideas 
   
   
7. Never quit learning.  Take classes.  Attend conferences https://www.idug.org/events/