System status automation
How many applications did you have to close manually the last time you shut down Windows? How many UNIX machines in your enterprise require dedicated consoles and someone to watch them? The most likely answer to both questions is "none." Why should the mainframe be any different?
A lot of my coworkers wonder what I've been smoking when I bring up this topic but I think it's something we can achieve. Unfortunately, our current strategy involving teetering mountains of shutdown and start-up automation won't get us there. Instead, I think IBM should move the layer of system status automation into the operating system as they did for the
For instance, MVS already has a broadcast facility to notify subsystems of events. Why not create a shutdown event that all subsystems can see and, most importantly, react to? Why can't z/OS support a start-up PARMLIB member listing the tasks and subsystems that should be initialized before or after the Job Entry Subsystem (JES)?
Shops have been working on both console automation and message suppression for a long time and I think most of us have advanced to the point where we don't need console watchers. However, this is another thing to think about when purchasing that next product or writing that next system utility. Is that Write to Operator with Reply (WTOR) really necessary?
Mainframe Maintainability Due to the mainframe's monolithic nature, the loss of one logical partition (LPAR), planned or unplanned, affects many users. Shops try to get around this with Parallel Sysplex facilities. However, things like software pricing have blunted the promise of Sysplex as data centers have to manage asymmetric configurations making it more difficult to manage non-disruptive outages.
There are several roadblocks to be cleared to reach the full potential of parallel Sysplex. First, customers need breaks in software pricing so they can quit juggling workloads.
Second, while IBM's major subsystems have done a good job exploiting Sysplex, some vendors and lesser known (but no less vital) IBM software has not. It will be up to IBM and the vendors to join the party.
Third, all mainframe software vendors need to build version and maintenance level tolerance into their systems. With rock solid inter-version operability a shop can confidently upgrade software concurrently with minimum disruption to the enterprise much the same as a lot of microcode changes are done today.
Maintainability has another dimension in the wild and wooly environment of parameter libraries. While, in general, I'm not a big fan of GUI "wizards" that hide too many important details behind dialog boxes, I can see where they are useful. They have the advantage of being able to edit system parameters for validity and consistency before actual implementation.
In addition, the next crop of systems programmers may have to depend on wizards until they can get deeper into the system. IBM is already moving in this direction with the z/OS health checker, the I/O gen application and CICS Transaction Gateway (CTG).
Increased innovation that resonates beyond Big Iron
The mainframe has a long history of innovation from virtualization to goal-based performance management. Indeed, it's laughable to read some articles for smaller platforms touting the latest "innovation" that IBM actually introduced in the 70's.
But I have the feeling that the mainframe lost the edge of technology with the advent of the Internet. IBM has done a wonderful job of continually enhancing big iron with specialty engines, availability improvements and open systems support.
However, a lot of these changes are local to the platform and don't seem cause any ripples outside of the mainframe's realm. Furthermore, while I'm impressed, in particular, how subsystems like CICS and DB2 keep up with the latest open system standards, these types of enhancements come out somewhat after the fact and have a "me too" feel.
So the question becomes what sort of innovations can the mainframe make that will drive changes for the entire IT industry?
These are the broad areas where I think mainframes can improve. Of course, it's easy for me because I don't have to do them. To accomplish them IBM will have to work very hard with ISV's to get them on board, not to mention all the myriad home-grown system software. But, these are things to think about to be better positioned in the coming years.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
Did you find this helpful? Write to Matt Stansberry about your data center concerns at email@example.com.