As one of the fairly new members into the mainframe family, I originally had some hiccups understanding the basics of mainframes. And by basics, I mean the absolute basics. I wish there was someone who could tell me a story of how it all happened from start to present in the mainframe world. A dear friend and a mainframe enthusiast suggested I read a book and the book clearly solved the purpose.Hence, here is a top ten list of the coolest z/OS facts.

1.      z/OS is an awesome multitasker

Back in the days, when z/OS was developed, computers were extremely expensive. Hence the developers built z/OS in such a way that different people could use z/OS to run multiple tasks at the same time. Every task that runs on z/OS runs in an address space and each task thinks that it’s the only one running. However, behind the screen, z/OS shares resources like memory and CPU across all tasks and there could be numerous tasks running at the same time sharing these resources.

2.      z/OS handles large workloads

It sounds quite obvious that z/OS can handle large workloads. But there must be a way to decide what tasks to run first and what can wait. In other words, how do we prioritize? z/OS uses a feature called WorkLoad Manager which helps in prioritizing system, production and non-production tasks. This helps z/OS in handling large workloads making 100% use of the CPU.

3.     It’s unbelievably hard to crash z/OS

Everyone expects z/OS to keep running and running and running. So anytime when a task crashes, we can not let that crash any other part of the system. Now remember we mentioned that every task runs in its own address space. So IBM has invested a lot of time and money in making sure that when a task crashes in one address space, it does not interfere with the normal functionality of the entire system, in other words making it robust and also clean up completely where the crash occurred so we can be up and running like new. But z/OS records any crash that occurs due to a hardware or software failure, so we can get into investigation later.

4.      z/OS has the best recording

z/OS comes with its own inbuilt scribe and we call it the System Management Facility(SMF). SMF records quite a lot of information like when was the system started, what task is currently running, when was a file created, when was it last edited, who deleted it, etc,. Security audits, capacity planning and performance monitoring are some of the uses of all this information that is recorded using SMF. IBM can proudly claim that z/OS has the most extensive recording of any operating systems.

5.     You need a job entry subsystem for z/OS

z/OS can run a series of jobs at the same time without any human intervention and they are called batch jobs. Users use a language called Job Control Language (JCL) to specify instructions for a specific job or a batch job to run. Once z/OS receives instructions from a user in the form of JCL, the role of a Job Entry Subsystem (JES) is to convert the JCL instructions into machine readable form and then queues them for processing, create address spaces, make sure all the input files for the job are ready, specify where the output has to be written and any other information required to run that job. Overall, JES acts like a manager, making sure, everyone has their resources to do their job and everyone does their job diligently.

  6.      How different are z/OS files?

                   We all know about files on windows. They store our data and we can access our files through an application like notepad. In z/OS, the concept of files is quite different. In the first place, they are not even called files. They are called Datasets. Each dataset is made up of records. When you create a new dataset, you need to specify the length of each record. Some other basic information that you need to specify are where the dataset should be stored and how big of a dataset it is. We will discuss about creating datasets and all the information you need to know to create a dataset in a later post. Hang in there!

               7.      How do you talk to the Mainframes?


How do we interact with such humongous mainframe computers and z/OS? We have to use an application called TSO/E( Time Sharing Option Extended) to talk to the z Systems. TSO/E is very hard to use. So z/OS comes with ISPF (Interactive System Productivity Facility). ISPF gives an interactive and easier way to communicate by providing lot of inbuilt functionalities

8.     You get UNIX with z/OS

When we say, you get UNIX with z/OS, that’s really an eye wash. What you really get is a POSIX compliant UNIX Shell called UNIX Systems services (USS). Posix compliant means that we meet all requirements to call it UNIX, but it’s actually not UNIX. 

9.      z/OS has a console

In your mainframe server room, you will have operators who would monitor your system on a regular basis to make sure if the system is running without any interruptions. The way they do it is, by monitoring the console with the system news feed to see what is going on in the system, if there are any alert messages or if there is any problem that they need to be aware of. The main z/OS console is directly plugged into the mainframe, so that even if there are network issues, the console will continue to work.

10.     z/OS isn’t enough

Once we successfully setup z/OS, we now have a basic operating system. But the real functionality of a mainframe is not exhibited unless we equip our system with applications that run on z/OS for security management, performance, database management, printing, etc,.  Apart from IBM, there are also other vendors in the market who sell applications that run on z/OS to make it more efficient.

If you need more of this, I suggest reading What On Earth is a Mainframe?
The book is a very easy read with topics ranging from fundamentals of mainframe hardware to application development on z/OS.
Posted in JCL.

One of the more unique aspects of being a Millennial Mainframer is working on teams with coworkers far older than ourselves.  While this generational gap impacts day-to-day life in a mainframe shop in meaningful and significant ways, our older coworkers, contrary to popular belief, were at one time themselves young IT professionals learning the mainframe platform.  I was reminded of this fact during IBM’s Pulse Conference when one of the speakers saw a group of Millennial Mainframers sitting together and commented that he felt “like he was back at an IT shop in the 1970s.”  In that light, it is quite useful for us to consider our elders’ experiences as young mainframers and perspective regarding the evolution of the mainframe platform.  Of course, many of the Baby Boomers grew up with the maxim “never trust anyone over 30,” meaning that we need to need to take their thoughts and advice with a healthy dose of youthful skepticism.

In 1964 (the very same year that Jack Weinberger penned the aforementioned Boomer maxim in the San Francisco Chronicle), a Italian-American college student studying Electrical Engineering in New York state began to get nagged by his mother.  While this student dreamed about moving west (out californee way), his mother wanted him to think about something more practical, like an IBM co-op program in the Hudson Valley.  After much gnashing of teeth, this student relented, which gave him the opportunity to work on the ferrite cores of the System 360 (the original predecessor to the System z mainframe).  Rather than experience the Haight or the counter-culture of the 1960s, this “magna summa cum nada” student (named Nick Donofrio) began a 44 year IBM career that brought him into “the primordial ooze” of mainframe computing.

In the following 40 minute talk to younger IBMers during the announcement of the zEnterprise, Nick Donofrio recounts his views of the past, present, and future of mainframe computing.  Despite having a length longer than the 30 second attention span of the average Millennial, this speech is worth a listen, as it is the best message I have ever heard for communicating the unique value of mainframe computing.  So fasten your seatbelts and hit play.  Heck, as a millennial, you’re a master multi-tasker anyways, so feel free to fire up DrawSomething on your favorite iOS or Android Device while devoting your ears to Nick Donofrio.

What are your thoughts?  Do you feel blessed?  Did Nick inspire you?  Do you want five honorary doctorate degrees?  Do you agree with his thoughts on the mainframe?  How do you plan to build on the mainframe’s legacy?  Let’s hear you in the comments!

Posted in IBM.

I was chatting with a friend of mine the other day, and he related to me how he was dealing with a lot of issues with outages in some key production I/T systems. His opinion was that the majority of this particular company’s issues were due to people problems and not to software or hardware defects. They were issues with lack of testing or configuration errors or just plain sloppy work. Interesting, but not unsurprising.

My first job out of college was as a mainframe systems programmer. I installed ISV products, IBM software subsystems, and eventually worked my way up to be an MVS systems programmer. I installed the OS, I installed and implemented maintenance, I debugged problems, shot dumps, trained operators, and did all the stuff that a sysprog does. And when I implemented changes, I had to package up those changes into a batch/scripted job that could be run after hours and install the changes with minimal human interaction. I also had to provide a back-out script that would allow the changes to be reversed if necessary. There was a team of individuals who did this FOR me – “Change Control”. The Change Control group scheduled, coordinated and implemented the changes. That way they could keep track of what changed and in most cases could isolate problems to a particular change.
So after I heard the horror stories from my friend, I reflected back on this first job experience and thought about how different it was then from what we generally see now where change is often much less controlled, and there is a lack of rigor in systems management processes and practices. Many of the issues we have with I/T systems are with the people and how they are administering systems, and not with the quality of the hardware and software.
Like Soylent Green, “IT is People!”
That’s where I come to The Mainframe Mentality. Around 2002, I put together a presentation called “Introduction to the Mainframe”, where I would spend about 2 hours introducing the mainframe to folks who had never worked with the platform. The last slide in the presentation was titled “The Mainframe Mentality”, and it was intended to help my distributed systems colleagues understand what mainframe people were like, and why. It was a bit of a psychology lesson.
IT is People.
While IBM System z hardware and software is indeed well-engineered for reliability and high-availability, technology can only go so far. In order for these components to deliver the quality of service (QoS) that it is capable of, the people that are managing, monitoring and administering the system must do it in a way that enables the technology to do its thing. If we are to expect System z – or any other information technology platform – to deliver, the people and processes must be an integral part of it. Over the years the IT industry has realized the criticality of this thinking. ITIL (IT Infrastructure Library) defines standards for processes and practices along the lines of what those of us with The Mainframe Mentality have attempted to do with systems/service management.
In my last blog post, I made a crack about “the good ol’ days”. I’m not really a “millenial,” per se. I have sons that are. 🙂 And I work with a lot of them. And I like to think that I’m mentally a lot younger than my body indicates. But I have a lot of years of experience under my belt in working with this stuff and I’ve seen many, many mainframe customers and how they do business. Almost universally, mainframe customers have well-defined systems management practices and processes that help them maintain excellent QoS. They have change management, capacity and performance planning, problem management, and other processes. They lock down system resources with security systems like RACF. They have good monitoring tools to watch what’s happening on the systems. The people aspects of system management are refined and well-defined. That’s part of “the mainframe mentality”
But there’s a flip side to this. There are a lot of mainframe folks who seem averse to change. They like the old stuff, like 3270 interfaces. They like to program in Assembler because it’s fast and it does exactly what they want it to do. They like online systems like CICS and IMS and look down their noses at WebSphere and more current technology. But why is this? Is it because it’s a threat? I don’t think so. I believe it goes back to The Mentality. These folks are concerned about keeping the lights on. They want to maintain that high level of availability and reliability and to be sure that the business stays running. This thinking can sometimes be a problem and a hinderance, but in the end these folks are pros at ensuring that mission-critical systems stay running. Those traditional technologies just plain work.
But so do the new technologies! A lot of folks forget that once upon a time, DB2 was a beta product with a lot of bugs and flaws. So were IMS and CICS. We have to dedicate the same kind of effort to hardening and refining implementations of some of the new tools and products on System z. Many of these “newfangled” products like WebSphere for z/OS are now on their fifth or sixth versions and have been shaken out over more than ten years of deployments now. They’re there. They work. But they still require industrial-strength processes to ensure that they have the same kind of bullet-proofness (is that a word?) as the traditional systems. And they’re sitting on an operating system and hardware base that can deliver higher levels of performance, scale and availability than any other.
But I/T is people. Those people still need “The Mainframe Mentality” to keep the transactions and data flowing…to make sure that I can get money out of my ATM or make reservations for my flight to Minneapolis….as long as it’s not in the winter.
Posted in Uncategorized.