I could write about aspects of simplification for z/OS for a week… but I will try and at least start this topic with a couple insights.

z/OS has been around for over 50 years. It was originally developed as an overarching replacement for the system ‘monitors’ that were around up to 1964. The ‘monitors’ that were around at the time would hardly be considered much more than a simple wrapper in front of the hardware. You can think of them kind of like the BIOS on a PC today.

Prior to OS/360 IBM computers required human operators. They would take your deck of punched cards and put them into a card reader. The cards represented a program or a set of commands, or a collection of data. Frequently the cards were copied to a reel to reel tape to make them more Then the operator would run a program by issuing a set of commands at the operator console. The program might select customers who are located in New York so that you could run another program to generate a printed report. An operator would read messages issued by the system to see what was happening, the operators were integral to recovery procedures as well.

One facet of OS/360 was automating the physical Operators (people) out of the system. You could run a job without operators. Frankly nothing could be further from the truth. One aspect of z/OS complexity is that its history is steeped in OS/360. That is good and bad. The system is very stable and predictable, but it often seems to be telling the wrong person about aspects of the problem that they aren’t prepared to deal with.

As an example, when a program fails hard in z/OS, the system will issue an ABEND (abnormal end), and take a Dump of memory. The message the job gets includes the internal state of the computer. This includes the registers at the time of error. The result of that… is rather than a message, such as ‘job failed’ you get a lot of odd information which tells someone what happened but typically not a low skilled programmer or user.

Sometimes making z/OS easier is just interpreting these kinds of results so that a normal technician doesn’t have to puzzle it out. I mean we all ‘know’ that an abend 822 is out of memory, or an abend 047 is an authorization failure, or an 106 is a module not found. Ok maybe we don’t all know that. This is just one small aspect of simplification that we are working to make better.

We have been using multiple strategies to simplify z/OS from improving messages, to converting return and reason codes to messages, giving you tools to lookup the messages, eliminating the messages to eliminating entire tasks.

Another aspect of z/OS is that the character set is Upper case text… if you type in a lower case character it is folded to upper case in some interfaces. However when you deal with standards based interfaces you are more likely to see case sensitivity as that is more common in newer API’s. This split personality is another aspect of complexity that we need to work on to simplify the z/OS experience.

In recent years we have delivered a local Knowledge Center that mimics the one on the internet. This local version is called KC4Z. You can run it on your z/OS system in cases where you can’t easily get to the internet. There are clients who don’t allow internet access… but you need the documentation. This provides a solution there. Additionally if you have a disaster and can’t access the internet for some reason but you need to see the documentation this can be a critical component. The KC4Z runs in a WebSphere Liberty runtime and requires you to maintain the documentation by downloading from an internet site. A few weeks back IBM rolled out a new KC on the internet called IBM Docs. While it has a lot of good features it will be a little while until we can replace KC4Z.

Other aspects of simplification, such as 3270 UI and some of the language is also a complexity people have to deal with. The 3270 UI once you become used to it, is actually very efficient. These days people don’t want to learn a single platform skill like that so we are working to provide web based alternatives such as z/OSMF and Zowe. While it won’t fundamentally make z/OS easier it will eliminate one of the skill requirements. The language complexity is for example z/OS calls memory which others call RAM, central storage, we call disk… DASD, we call CPU’s… general purpose and specialty engines etc. In software SMP/E is used to install software and has things like FMIDS, Hold data, global zones etc. Some of this we can simplify just by using the names every one else does. However in some places the names are very specific and helpful in expressing problems or solutions.

In a future blog I will discuss more about z/OSMF.