There are several tools that are used to simplify mainframe research and analysis of that complex environment. Most of them are green screen based and require knowledge of z/OS ISPF panels and arcane command syntax, that once familiar to a z/OS Systems Programmer, can become second nature.

But in today’s integrated IT world, z/OS system programmers aren’t the only people who need access to research, test, and analyze in the z/OS environment. Application and Systems Developers, Integration Engineers, Business Analysts, and a myriad of other IT professionals do too. To these new-to-z/OS IT professionals, the interface into z/OS is just that – arcane and uninviting.

Having grown up in a world of mouse clicks and drag-n-drop editing, the emulators used to simulate the 80-column green screen interface are anathema to these younger IT professionals. These emulators are constrained by just the interface itself – a 24 line by 80 column view. There is also a 32-line, 80 column view option that offers one significant advantage – it allows the display of the function keys and what each function key does at all times. For new learners of z/OS that is a very significant advantage. But as always there is a price to pay for those 32 lines and in this case you give up the 132 column view when you are looking at printed output (which includes generated reports as well as system logs etc.)

In the 24-line mode, the switch to 132 column view is automatic when you flip to screens that contain that type of output, but you better know your function keys because their usage is not visible anymore. That switch in and of itself is somewhat annoying, but it does help to see the entire line across the screen (there is no scroll bar to just scroll right/left, or up/down). This does make the copy/paste functions easier.

The lack of the 132-column display in 32 line mode seems to be a joy killer for most seasoned mainframe personnel. Lastly, you cannot easily switch between the 24 line and 32-line views as it requires a separate emulator session to invoke those settings.

With all of the above said, this article is going to focus on just one aspect of green screen usage, and that is for managing, viewing and supporting an IBM MQ environment on z/OS. Yes, you get ISPF panels to be able to see the environment on z/OS, but here, without the 32-line view, it becomes very difficult to remember what all of the function keys actually do. And you of course need to know those commands that have nothing to do with IBM MQ itself, just with how to manipulate the green screen interface.

As with all products on z/OS, IBM MQ uses RACF to control user access. No matter how you administer the product itself, you will always need to tie user access into IBM MQ via the tools you use to provide that access. This article will assume that RACF is used for that control. But other security products like Top Secret will have similar usage mechanisms. The issues with security come down to application level access. There are a few distinct types of access required –here are some examples:

• Real time transactions running in CICS that do not use real person UserIDs but instead use IDs that have been granted authorizations and cannot be used to log into the system
• Batch jobs running under system level IDs which again cannot be used to log into the system
• Real person UserIDs that are actual people performing their job functions using the green screen interfaces such that you want to ensure that the transactions they enter are performed under their IDs
• System administrator IDs
• Technical development users that need to see the environments and be able to manipulate things without help from an administrator in the test environments, but have limited access in production environments
• Business analysts that are similar to the technical teams above, but probably only need view capabilities in any environment

With that list of users described above, it becomes obvious that the security rules used to control the environments can get quite complex quite quickly. All of those rules need to be in place, but then you also have a wide variety of users that would all require training on the z/OS systems in use, and that is where things get tougher.

To mitigate the training needs for z/OS as it relates to IBM MQ, assuming you have developers and business analysts that have little to no understanding of z/OS interfaces in the first place, we can introduce a third-party utility that will let you push the security rules into a GUI based system. Avada Software’s Infrared360 product is one such utility tool.

This doesn’t mean the security rules are any less complex, in fact it actually gives you more granular capabilities, which in some ways makes the administration a bit more complex, but the capabilities of that granular control outweigh the disadvantages of administrative tasks when it comes to supporting the needs of the user base described above.

The major benefits of Infrared360 is that you can grant the utility itself very strong authorizations, even administrative capabilities if desired, and then control the user access outside of z/OS. This makes the security rules on that platform less all-encompassing restricting the user groups who don’t ever need to directly access the mainframe green screens from having that access.

With that, you now have a point and click interface into the IBM MQ world that is much more navigable than the ISPF panels, and can very granularly set the limits as to what Queues / Queue Managers any individual or group of individuals can see. It also specifies the capabilities: View only, PUT/Delete messages in and from queues, see details of object attributes, and if desired, set the administrative users to be all powerful and allow object creation deletion, etc.

If the tool becomes known to the z/OS IBM MQ administrators, then they have a common interface to discuss application issues with the various users that are in contact with them to resolve issues in any environment. The ability for each person in the discussion to be able to see the other person’s perspective (and the messages themselves) on the platform they are unfamiliar with is a very powerful capability. This will often lead to quicker problem resolution thereby freeing up resources for other tasks. It may even lead to an app developer not even requiring a z/OS MQ resource to solve an issue – the perfect example of the use of a tool to stop the unnecessary time wasting of expensive resources.

A big thank you to David Corbett for sharing his insights on managing IBM MQ on z/OS and the benefits of using a GUI-based tool.

If you want an easier way to monitor and manage MQ, see how Infrared360® can help.

Want to see it in action?
Sign up for a free demo—we’ll walk you through it and answer any questions. No hassle, no pressure.

Schedule Your Free MQ Consultation