IBM Mainframe Forum

Hello everyone!

New to the forum and happy to be apart of the group. I come today to ask a couple questions concerning MVS systems programming. Been doing mainframe for 6 months now and I'm curious as to what is expected of an MVS Systems programmer once they have reached an Expert LEVEL. Essentially the day to day procedures not just IPLs, RESCLONES and Disaster recovery. What are some of the cleanup procedures and maintenance task that we perform?

To some degree, it depends upon the site and how it does maintenance. IBM releases maintenance monthly for its software (RSU -- recommended service upgrade -- and PUT -- program update tape, although this is being phased out) and while sites rarely install the maintenance as it comes out, usually the maintenance is applied after so many months (3 to 6 is common). Independent software vendors (ISVs) also release upgrades which need to be installed, either to stay in maintenance or because the upgrade fixes a problem or adds desired functionality. A small site may have 6 to 10 ISV products installed; a large site may easily have 20 or more ISV products. And while IBM's maintenance uses SMP/E pretty consistently, ISV products may or may not use SMP/E -- there are many ways they have to install maintenance and not all of them are system-programmer-friendly.

Most sites use multiple sets of system volumes to allow maintenance to be applied in a test environment (aka sandbox LPAR) before it can impact production (not all maintenance goes in with no problems); when the maintenance is ready to go into production there's an IPL of production pointing to the new system volumes to implement the maintenance. IBM's recommendation is to install preventative maintenance at least 2 to 4 times a year. In the meanwhile, IBM can release HIPER, PEFix, Security/Integrity and Pervasive PTF (program temporary fix) throughout the year and if these impact the system then they should be installed quickly since otherwise bad things can happen to the system. Once maintenance is applied, there's some cleanup done on the SMP/E zones to get them ready for the next cycle of upgrades.

There's also planning for the next operating system release. Yes they are now 2 years apart instead of 6 months apart as they were a few years ago, but the system programmers still have to plan the upgrade, order the software (which usually includes verifying ISV software either works with the new release or ordering the appropriate upgrade from the vendor), prepare the system by installing the new release and all affected ISV products, test the new release (which requires some applications testing), and then migrate it to production on an agreed schedule. There also needs to be a back out process just in case the new release is discovered to be unusable after implementation (this has happened to me a time or two and it's always highly stressful). Recent releases of z/OS have EACH added several thousand cylinders to the system volumes, so making sure there's enough space for the maintenance to go on is another requirement. If the site is small, the system programmers may handle storage, data base, CICS, Websphere and MQ Series management, and these activities can each take some time each month. A larger site will have dedicated system programmers for these functions.

Disaster recovery requires making sure all relevant data sets can be recovered, and hence there is generally one or two DR tests a year where the backup tapes go to the backup site and the system is restored there. Some sites use replication, but that merely means the tapes are not transported; the recovery process still needs to ensure a usable system is running at the DR site by the end of the test. CICS needs to be started, data bases activated, and in general the system at the DR site should mirror the production environment as closely as possible. Writing and validating the jobs to do the backups and restores requires some time regularly from system programmers (as the system changes, the backup / restore jobs need to be changed to match).

These users thanked the author Robert Sample for the post (total 2):

vasanthz (Wed May 10, 2017 9:55 pm) • bkw88 (Tue May 09, 2017 7:59 pm)

Thank you for the very informative response Robert. Currently my day to day is about 80% of what you stated except for the OS Release which is handled by my senior. We are currently in the process of implementing 2.2 and by (ISVs) im assuming products such as CICS,DB2,Guardium etc. We also must maintain up to date RSU and PUT levels on a monthly bases for 1 of our SYSPLEX through the process of RES cloning and applying new maintenance and ipling to the new volume. I guess the question I'm asking is what extra cleanup work could I do. The only extra task i've been doing outside of maintenance is:

Cleaning up APF list
Keeping PARMLIB/PROCLIB clean and up-to-date
Obsolete Vendor Dataset cleanup

ISVs stands for Independent Software Vendors other than IBM. They write software that run on mainframe, companies like CA, Rocket, BMC etc..

Yes, the products you listed are all IBM products and hence would NOT be considered as being from an ISV. Compuware, CA, Phoenix, MXG, Rocket Software, ASG, and BMC are some of the independent software vendors -- but there are many others not mentioned here.