z/OSMF or z/OS Management Facility is a component of z/OS. It has been expanded every release of z/OS since z/OS V 1.11. The latest version V2.5 has introduced a desktop user interface. Through the desktop UI we are giving customers an alternative to the 3270 user interface for many parts of z/OS management and administration. The idea is to provide a base component that gives the tools required to manage z/OS. It can also act as a pluggable interface to connect to other tools whether on z/OS or on a non-z/OS platform.

In my opinion, z/OSMF will never be able to provide all the management tools that customers want or need. This is why it is pluggable. Should a customer want to connect to other browser based tools they can save links in z/OSMF and publish them for others in their installation to use as well.

Zowe is just one UI that could be linked to from z/OSMF. z/OSMF is intended to be present in every z/OS deliverable and it is highly recommend that customers configure at least one instance in each sysplex. A customer can configure Zowe to link to z/OSMF as well, they might choose to make Zowe their goto interface. There really is no problem doing that either. Here thought I want to talk about what you can do from the desktop UI.

First when you login you will see a desktop. There may be some icons on the desktop. If you right click on the desktop you can create a folder. Folders can contain objects. One type of object is an application icon. Another is a link which is like a bookmark stored on z/OS. Links are private to a particular user. You can give folders names, you can arrange them on the desktop.

If you go to the action bar on the bottom, you will see icons on the left that can take you to additional information about z/OSMF. One of the shortcuts will enable you to explore the z/OSMF services (REST Apis) through their Open API specification or commonly known as Swagger documentation. The API explorer function provides a simple interface to even try out the API’s.

On the right bottom side is a magnifying glass. This will let you look for datasets or files. It is like ISPF 3.4 you can search for datasets by name. When you find one you can click on it and it will bring up a member list and clicking on a member will bring up a browse window. You can also save a shortcut to either a dataset, member, or file on the desktop or into a folder. You can toggle the browse window to edit mode to edit a dataset. If the type of data is REXX, JCL, XML, or HTML then a syntax highlighter is enabled. If it sees a pattern that appears to be a dataset or a file path it will enable hot linking on that name which will browse that object.

JCL objects can be submitted to the z/OS local system to run, this causes a basic spool browser to be started in another window. Through that interface you can monitor jobs and view the output.

So the desktop not only provides access to the various z/OSMF functions, it also provides replacement function for ISPF 1 and 2 (browse, edit) and part of ISPF 3. You can allocate datasets, search for datasets etc. You can also do output processing, ISPF 3.8.

What function in ISPF would you like to see added to the browser interface?

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.

For z/OS 2.5, which we recently announced, there have been a number of statements of direction around changes in functional content of z/OS. I will focus on the removals that planned in this blog.

First and by far the most significant is the removal of JES3 (Job Entry Subsystem 3). z/OS has had two JES implementations that grew up from customers. JES2 or HASP and JES3 or ASP. For years JES2 has dominated the customer base both in number of sites, operating system images, and even size of image. The largest customers run JES2 these days. Years ago, before parallel Sysplex it was common for large customers to run JES3. Without any encouragement by IBM the customers have largely moved to JES2. The features being added to the JES components have therefore been focused on JES2. As a result IBM announced in 2017 that JES3 would be removed from z/OS in the future. In 2019 this was reiterated in another announcement. The z/OS 2.5 preview reiterated this again and indicated that 2.5 would be the last release to include JES3.

JES3 customers have the option of migrating to JES2 which is included in z/OS, or another option is to use JES3Plus. Phoenix software is offering a JES3plus. The JES3Plus option intends to run a JES3 derivative product on z/OS which would maintain all the existing exits, JCL/JECL, Operator commands and operational procedures. JES2 migration does require customers to change all those items as part of the migration. The migration to JES2 can be time consuming but there are vendors out there who can do a lot of the migration for a fee.

In addition to JES3 we also announced the Bulk Data Transfer – BDT feature will be removed in a future deliverable. In fact BDT is only planned to be retained in z/OS through V2.5. BDT comes in two priced features, SNA/NJE and File to File (FTF). The BDT SNA/NJE version is only applicable to JES3 customers. JES2 customers have SNA/NJE built into JES2. BDT FTF is applicable to both JES2 and JES3 customers. But BDT is a very very old technology base, it assists customers to copy and move datasets from one system to another. An astute reader will recognize that moving datasets could be done today with FTP, with SSH, with MQ file transfer, with Sterling Direct, or any number of vendor options.

So again here BDT customers have the option of migrating their functional requirement to one of the other IBM options or they might want to look at the Phoenix offering announced for BDT similar to JES3Plus.

Beyond this we removed the need to specify maxsharepages. This setting was put in place to control the consumption of common storage which used to accompany the use of shared memory. The real storage manager no longer needs any common storage for using shared memory. So the option becomes obsolete.

We’ve also removed some HFS options (as opposed to zFS) since we have deprecated HFS. There are also some removals in the communication area. We replaced the SSL configurations of TN3270, FTP and DCAS to use AT-TLS policy. This not only unifies the the configuration but also brings the code up to the most recent level of capability.

Lastly in ISPF, the workstation agent has been removed as well as the support in ISPF for HFS.

While there are quite a few removals these should reduce the need to know about these features or capabilities as they are essentially no longer needed.