Bookmark and Share

Recent Posts

Install, Verify and Move System Software to Production

October 30, 2017

This is the fifth post in a series about things they never taught me in school. When I took computer courses at a university and from in-house training programs, I never learned anything about the steps to install and make system software ready for test then production use. For the first 10 years that I installed products, I learned just about everything from the product manuals and IBM Redbooks. I am sure there were courses about aspects of the products that I installed and supported, but there was little education funding and most of the skills that I discovered were perhaps best learned through practice. Let me explain.

A Product and Its Universe  

A few years ago, I went to a piano recital where the artist was playing a grouping of late Beethoven piano sonatas. In the program notes, it was written, “with each work, Beethoven creates the sonata in such a way that it is its own universe.” Really? Each work a universe? I listened to the concert and realized that the notes in the program were exactly correct. When each sonata began, there was a mood and feeling established that developed throughout the piece. When the next sonata began, there it was—a new universe. I was amazed.

Software products aren’t piano sonatas but, like musical works, they have sophistication, relationships between elements, maturity over time through releases and significant usefulness. When you install, verify, test and move products like IMS or CICS into production, you’re working in a space deeply focused on the features and functions of these products. In a very real way, you are working in that product’s specialized environment, its universe full of special terms, conventions and practices. Software products aren’t art but at times, are they not artful?

Product Install  

For almost all products on mainframes, the product install begins with planning. Typically, you can’t just submit jobs; you have to do some planning. Creating a plan with resource requirements, tasks and a timeline is a necessary first step. Most IT shops have a template or common practice for this activity.

Next, you use super utility SMP/E to receive, apply and accept one or more function SYSMODS, which is the product itself. You also install required product maintenance. These steps build libraries that are used in a variety of ways in later steps. If the phrase “function SYSMODS” seems abstract, that’s because it’s conceptual and is something you learn as you do it and make mistakes (e.g., not running “apply check” before you run the actual apply function). When SMP/E was new to me, I was concerned with all its perceived complexity. Over time I realized how to make it work every time and got the sequence done quickly so I could move on to real work of product administration, testing and verifying functionality.  

Product Verification

Most products have an installation verification procedure (IVP). Here are some examples:
The IVPs are good teaching tools for new system programmers and typically they’re just part of the required testing scheme. At some point, you need to invite the application programmers to check out the new release and since they are busy people, it’s a good idea to include their efforts in the overall installation and testing plan.

Configuration Work

Before you run the IVP, there are usually configuration procedures to handle like submitting jobs or making changes to members of product libraries. This configuration work is administrative (not customization) because there are sets of steps you follow right out of the installation manual. These are activities that require thought and human interaction so they can’t be easily handled in the SMP/E steps. For example, a product like NetView has a lot of documentation on installation and configuration procedures that need review and potential action because many NetView users have made extensive use of its varied product functionality.

Challenging but Rewarding Work

Product installs of important products is challenging, even scary work. If you are installing and administering an environment heavily used by application programmers and you’ve never been an application developer then you are at a disadvantage when helping to solve application problems with a new product install. It’s a situation where you learn a lot quickly out of need. A few weeks ago, I read a job description for a senior CICS systems programmer on a job posting site and asked myself—who has all these product skills and is able to handle the uptime pressure of a banking environment? Of course, if you have the skills and experience, the job will be satisfying and you will be paid well.  

Next Week

Next week, I’ll finish up the series by explore something else they didn’t teach me in school: How to design and develop large-scale system software with a special relationship to the OS and enterprise middleware. This activity is filled with enormous challenges and rewards.  

Posted October 30, 2017| Permalink

comments powered by Disqus