Db2 for z/OS v13 Installation: A Gen Z Experience

I joined IBM shortly after I graduated from the University of North Texas back in 2019. I was full of excitement and eager to embark on my first ‘real’ job. Little did I know, I was about to spend the next 4 years drinking from a fire hose… I joined the IBM Z ISV Center and at that time, they were looking for someone young to learn more about Db2 for z/OS from the two tenured Db2 systems programmers on the team. I already had some exposure to relational databases through my coursework at my university and from IBM’s Master the Mainframe competition. I also graduated with a degree in business analytics. So naturally, I was looking forward to learning more about the technology.

It was late July of that same year, and it was just my second week on the job. My two mentors, who had over 60 years in the industry between them, announced their retirement at the end of the year. I was crushed. I only had about 5 months to learn as much about Db2 as humanly possible from them. Once the new year began, I was on my own. Maintaining all Db2 for z/OS subsystems for my team. Luckily, I gained a lot of mentors in the lab and throughout IBM. I had to find mentors or else I would’ve been in big trouble. That hunger of wanting to know more and understand other people’s experiences and knowledge lead me to 2022 when I was able to install my first Db2 when it became GA: Db2 v13. Today, it is used by Independent Software Vendors (ISVs) across the globe.

The IBM Z ISV Center provides products and services to IBM’s business partners and ISVs alike. To put it simply, we deliver packaged systems to ISVs to test/develop their products, among other things. We provide the latest and greatest IBM software and hardware as well as the most current RSU/PUT maintenance level. Our environment is provided solely for developmental purposes and, therefore, we do not handle any production data and performance related workloads are not considerations for us. This is important context as the nature of our environment heavily influenced the planning process for my Db2 v13 installation.

So, what does a Db2 v13 install look like in my environment? Today, I want to share my experience with the installation process and walk you through what I did and why. Along with some key takeaways I learned along the way.

First, I needed to decide what kind of installation method would work best for my environment. Since I am in a development environment, I didn’t need to carry any existing data from Db2 v12 to Db2 v13. Most of my ISVs can easily recreate their own database objects and prefer to rebuild their database environments when upgrading to a newer version. For me, the choice was clear: a fresh install. If I were in a production environment, I would more than likely have performed a migration of the members in a Db2 data sharing group. After deciding on my installation method, it was time to order a copy of Db2 for z/OS from IBM.

Shopz and SMP/E installation

The first stop on my installation roadmap was Shopz, the IBM web application used to order z/OS software products and services. When ordering a product, I had two options: CBPDO and ServerPac. For my install, I chose CBPDO (Custom Built Product Delivery Option). This is the standard method for my team when installing z/OS products. Once the code was on the z/OS system, it was time to perform the SMP/E installation. I won’t go into a deep dive of the whole SMP/E process, but this was a necessary step when installing Db2 for z/OS and it’s worth mentioning here. The program directory that was delivered with the product provided step-by-step instructions to make the product code available to the system.

Db2 installation

Once I completed the SMP/E installation, it was time to install Db2 itself. This is where the IBM Db2 for z/OS Installation and Migration Guide really came in handy for me.

z/OS Considerations

There were some z/OS considerations that I needed to account for in my installation. This included PARMLIB updates, link list options, and DFSMS. Side note: the configurations in your environment will likely differ greatly from mine.

For z/OS itself, I made changes to the following PARMLIB members: BPXPRMxx, IEFSSNxx, PROGxx, and IEASYSxx. I added my Db2 ZFS mountpoints to BPXPRMxx that will be mounted at IPL time, defined the Db2 subsystem so it can be initialized during the system initialization, and defined the APF libraries and LNKLST in PROGxx. By setting up the link list in the PROGxx member in PARMLIB, my programs and procedures will be able to find the load modules they are looking for without having to specify the libraries in JCL. Lastly, I updated the system parameter list, IEASYSxx, with the updated PARMLIB members so that they were loaded in future IPLs. 

I also set up ACS routines so the Db2 catalog and Db2 directory would be SMS managed. Since the release of Db2 for z/OS v10, SMS management for the Db2 catalog and directory is a must.

Generating jobs via DSNTINST

While installing Db2, most of my time was spent in the installation CLIST, DSNTINST. This CLIST is provided to aide in the installation and customization of Db2 by guiding you through a panel-driven interface when executed. These panels prompted me to supply my own parameter values or accept the supplied default values. In most cases, the fields corresponded with Db2 subsystem parameters (ZPARMS). I executed the member DSND10.SDSNCLST(DSNTINST) from the ISPF Command Shell which brought me to ‘DB2 13 INSTALL, UPDATE, MIGRATE AND PROVISION’ main panel.

The CLIST will generate tailored installation jobs for installing Db2. Depending on the INSTALL TYPE value that is specified on the first main panel, the generation of tailored jobs will differ. These values are not set in stone, so they can be adjusted at a later point in time.

For my installation, I chose to install a single instance of Db2. I used the default input file DSND10.SDSNSAMP(DSNTIDXA) and changes that I made to the default parameters in the panels would be printed to the output member, DSND10.SDSNSAMP(DSNTIDXC). One of the biggest challenges I faced when starting to learn Db2 for z/OS in my environment was all the naming conventions we used. To help get a better understanding of these conventions, I submitted hlq.SDSNSAMP(DSNTIJXZ) to export the settings of our existing Db2 v12 subsystem. I wish I learned about this job sooner in my Db2 journey as I use it to this day to help me understand my ISVs and their unique Db2 ZPARM configurations.

For my installation, I opted against using z/OSMF workflows. Although z/OSMF workflows can simplify the installation process, the installation itself was only one of my objectives. What I really wanted was to understand the mechanisms working silently behind the easy buttons provided by z/OSMF.

DSNTINST Output

Once I was done working my way through the panels, the CLIST generated the jobs list below with the parameters I specified to DSND10.NEW.SDSNSAMP and DSND10.NEW.SDSNTEMP.

Anna’s definitive guide to navigating the CLIST parameters

Now I know what you’re thinking. “Anna, I just want an easy one-pager that will give me all the answers to the panels. Kind of like those cool infographic pictures!” And because I’m feeling generous, I decided to provide you with just that. This is Anna’s definitive guide to navigating the CLIST parameters in DSNTINST. With this straightforward guide, running through the CLIST is now easier than ever before (pilot’s license not included)!

Submitting JCL and starting the subsystem

If you defined everything correctly, it should be smooth sailing from this point. If there were any modifications that needed to be made to the jobs, this was my time to do so. The IBM Db2 for z/OS Installation and Migration guide had recommendations that I used when determining the order in which to submit the jobs. These jobs defined active logs, boot strap datasets, Db2 catalog and directory objects, buffer pool sizes, among many other things. After the installation, the subsystem was at function level 501. The catalog level was also at 501.

Since I made PARMLIB changes for my installation, I had to dynamically load in the new members before I started the subsystem otherwise the startup would fail. If you have PARMLIB members that do not support dynamic loading, an IPL will be required before starting up Db2. Finally, we’re at the point where we can start Db2. Woohoo! My heart always beats a little faster when I’m starting up Db2 for the first time. Once the Db2 successfully comes up, it is always a good idea to verify the installation with some testing. The Installation Verification Programs, or IVPs, are sample applications that verify the operation of Db2. Completing the IVPs will not only verify that the installation has been done properly but it is also a great tool to get a better grasp of how Db2 works. I strongly recommend completing the IVPs if you are new to Db2!

Key takeaways

My key takeaways from the whole process:

• Don’t be afraid to ask questions. This was, and to this day still is, beaten over my head as someone who is new to IBM Z. There is real value you can gain from struggling through a problem, but on that same note, don’t underestimate the value of expediting your learning experience by someone who has already done the struggle for you. It’s for sure a balancing act and it’s still something I’m learning to this day.
  
  
• If you have access to a sandbox environment and have the opportunity to install Db2, do it! You will learn so much from the process. It’s something that I wish I had done sooner in my learning journey because it helped give me a bigger picture of how all the pieces of Db2 fit together. Same goes for the IVPs.
  
  
• Lastly, beware the dangers of the dreaded “because that’s the way we’ve always done it”. Just because it has been done a certain way for a long time doesn’t mean that it was always the right answer. As you gain more experience, you will start to see how you can improve processes and be a contributor to making something better for yourself, your team, or maybe even your company.

I welcome your comments and questions.