Could anyone please guide me regarding ZOS system programming . I wanted to join the course. I have around 6 years of application development experience in mainframe. What are the different area I should look for under this course.
Joined: 06 Jun 2008 Posts: 8165 Location: East Dubuque, Illinois, USA
System programmers need to understand Assembler, SMP/E, utilities, debugging, system functions such as initializing disk packs and doing an IPL, JES, and so forth. CICS system programmers specialize in CICS installation and support. Some system programmers do nothing but install and support independent software vendor packages.
The best place to start, in my opinion, is learning SMP/E and understanding the various parameters of SYS1.PARMLIB (which are in the Initialization and Tuning manual for your version of z/OS).
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
From some of the best sys progs I have known, being a sys prog is an art rather than anything else.
If an organization was very fortunate, yup, such artist(s) were there.
It really is something indeterminable that great sys progs have.
Yup again. . .
I'm not sure exactly what you call it but, i believe that things like curiosity, persistence, and the ablility to see past the reported
"symptom/issue" to the real issue (requirement or problem) help define these special people (and they are not all sysprogs). Being able to quickly grasp the heart of a matter and see past distractions is indeed an art.
However, i believe there are very many quite solid technicians who are responsible for the successful "care and feeding" of the majority of the best run data centers. Indeed, with the size and speed of the newer systems, more is being done on one "system" than ever before. This has led to most of the technical infrastructure becoming more science than art.
Once upon a time, a sysprog pretty much "did everything". These days there is a high degree of specialization. Once upon a time almost every software vendor had their own special way to install/upgrade/fix their products while today more (if not most) use smp/e. Way back when, we all had the complete source to the operating system - and made some rather bold modifications to accomplish things the operating system did not provide. The good news was that if a thing was needed, it could be slipped in. The down side was that an upgrade or fix could knock out your magic. To accomodate customization, there are now zillions of places/exits to invoke custom code without the danger of modifying the actual operating code.
Back then, people who could work magic were indeed special. These days, i believe the best environments are the ones that quietly run all day every day. If the center allows too many "special things" they tend to wind up with "special problems".
If you want to become a sysprog, i'd suggest you become very comfortable with assembler (not that you will likely write it much, but it is one of the best ways to understand what is happening at a lower level). As you look at assembler, pay more attention to system code rather than application code. You would also want to learn about the various major components of the environment and how they relate. Beneath the major components, learn to navigate the system "control blocks" or data areas. You should become comfortable with the various standard utilities. Many exceptional sysprogs got started in application development or production support.
Something i've told people who i've worked with for many years is that if they tell me where they want to go, i will do what i can to help them get there. If you want to become a sysprog in the organization where you are working now, it may help to speak with your manager about your interest.
And, yup, even though i understand we had to move on, i surely do miss those days. . .