IBM Mainframe Forum

expat wrote:That's a little like comparing apples to washing machines.

TSO ? ISPF ? REXX ? Keeping them Straight

What I used to think of as a minor annoyance, I now perceive as a larger (and growing) problem. This problem is: Co-mingling, blurring and cross-pollination between all things that have to do with TSO, ISPF and REXX (and CLIST for that matter). On a number of Internet help boards that deal with mainframe subject matter, this mix-up problem seems to be growing. Quickly.

I'm certain that what is at the heart of the problem is: Lack of training, no mentoring by more senior technicians (who truly understand how this stuff works) and the complete dearth of any formal university level education about anything having to do with the mainframe. People today just seem to be thrown into the mix and left to fend for themselves.

Is this due to Baby Boomer mainframe folks retiring? Probably. Or is it related to the increasing numbers of offshore technicians being asked to step up to bat and code? Certainly. What about newly minted Computer Science graduates suddenly finding themselves earning their daily bread on the mainframe? Yes indeed. I've seen this first hand.

Why Is This a Problem?
It is a problem because people who are charged with creating or maintaining TSO/ISPF/REXX software these days don't seem to know where to look to find the answers to their questions. Or, they don't even know how to ask a question correctly.

This is what the balance of this month's column will attempt to explain. How to mentally segregate the various components and then use this baseline knowledge as the starting point for getting questions answered.

TSO (TSO/E)
I might as well start with the oldest piece of software on the planet. TSO, now named TSO/E (Time-Sharing Option ? Extensions) has existed since around 1970. It solved a long-ago time-sharing problem (hence the strange name) back in the days when computers took up entire rooms and could only do one thing at a time.

IBM still refers to the basic operation of TSO as a Terminal Monitor Program (or TMP). Essentially, this concept of terminal monitoring is the essence of TSO. What is being monitored? The press of an AID (Attention Identifier) key by any one of the TSU (time-sharing user) address spaces currently active on the operating system or LPAR (Logical Partition). AID keys are keys like Enter, PF keys and others such as PA1 and PA2.

I wrote an entire History of TSO series a few years ago. If I may, I will refer readers to this series for more details. It is available at a web site named http://www.tsotimes.com and consists of four parts ? Part I through Part IV.

TSO/E components can be segregated (as can many things) by the prefix that IBM uses to help identify components of subsystems and other pieces of the operating system. TSO/E uses the prefix IKJ. Don't underestimate the power of this simple technique - the idea that you can identify something that IBM produces by its prefix. It is quite effective.

Put simply, if a message or program or some sort of feedback begins with IKJ, look to the TSO/E documentation for resolution. Not REXX or ISPF documentation.

TSO/E is capable of running all on its own, without REXX or ISPF. The only prerequisite is the presence of a started task typically named TCAS (Terminal Controlling Address Space) or TSO. This address space is usually started just after an IPL and runs until the next IPL. It is the polling server for all time-sharing users who are logged on to a particular LPAR.

TSO/E (and it's predecessor TSO) are truly ancient. As a human-computer interface, TSO/E is similar to the old C: prompt of MS-DOS. When your TSO/E session is fully active, all you will see on the screen is ? READY. You might even ask yourself: Ready for what?

For a typed command, that's what. Traditional TSO/E command programming is not for everyone. It is a bit old-fashioned and is best done in Assembler. REXX and CLIST programs are an exception to this. I'll cover these languages in the last section.

In a nutshell, that's TSO/E.

ISPF
ISPF first appeared on IBM mainframes in the late 1970s, more than 10 years after TSO first appeared. Back in the 1970s, it was known as simply SPF. It's important to keep the historical timeline in perspective here. ISPF (SPF) came after TSO and was designed to make everyday TSO users more productive - particularly on those new-fangled 3270 full-screen terminals.

I would say it has succeeded. A good analogy would be comparing TSO/ISPF to older Windows environments and MS-DOS. On a pre-Windows PC, everything had to be typed at a command prompt ("C:/"). When Windows came along, it sat on top of DOS and provided a much easier-to-use interface.

This is practically identical to the TSO/ ISPF situation. The only difference, of course, is that ISPF is also ancient, has no graphical capabilities and totally relies on an underlying TSO/E session for data communications. This last point is critical to understanding how ISPF interacts with the end user.

Since ISPF depends upon the TSO/E Terminal Monitor Program, all actions taken within ISPF require the press of an AID key. Nothing gets communicated unless one of these special keys is pressed. This is true of TSO so by extension, it is also true of ISPF.

ISPF is both a canned end-user environment and a complete set of sophisticated services that programmers can use. I'll call this set of services the ISPF API (Application Programming Interface).

Most sites perform some form of customization to the canned IBM distribution of ISPF. IBM provides a complete set of tools for tailoring ISPF to a site's specific requirements. These tools allow customization at many different levels. Many sites go even further and perform their own user modifications (such as panel alterations) to the baseline ISPF.

Good for them.

For most people who end up using ISPF, that's all they do ? use it. Whether they use it to edit data, monitor and submit batch jobs or perform other maintenance and operation work, they never delve into the ISPF API.

Some people have a ball with the ISPF services ? TBCREATE, DISPLAY, FTINCL, QUERYENQ ? there are a ton of services that can be used if you're willing to write a little code. I have "written a little code" under the ISPF API since 1982 and if you're a regular reader of Working Smarter, you'll know what I mean.

ISPF components begin with either: ISR or ISP. I'll leave it at that. If you need to look something up with regard to ISPF, this is your starting point. I'll also point out that there are a TON of ISPF manuals. Take a few moments out on the Internet at IBM's publication site to familiarize yourself with this wealth of ISPF documentation.

REXX (and CLIST)
I don't want to totally short shrift the venerable old CLIST language but I have limited space. I'll just say that the CLIST language is nearly as old as TSO itself and for your analogy? Think of an MS-DOS ".bat" file with a few extra bells and whistles.

REXX has all but replaced the CLIST language on z/OS and this is a good thing. I wrote hundreds of CLIST scripts between 1976 and 1992. No more.

When REXX made its way to TSO/E, I knew I had to try it out. Gradually, I began writing more and more REXX code and by the end of the 20th Century, I had all but abandoned the poor old CLIST language. Why? REXX has many advantages such as:

? The ability to directly address memory
? Case-insensitive, both in its source syntax and text within variables
? Clearer, more intuitive syntax
? Portability
? Far better math capabilities
? Huge set of Built-in Functions (BIFs)
? Easier to learn (and teach)
? Many more

Something that I must mention is that CLIST code is still very viable, supported and runs just fine. It is no longer preferred, that's all.

The main thing that I want to say about REXX in this brief column is that it is a programming language. To many readers, this sounds all too obvious. But trust me, one of the most common gaffes on the Internet these days goes something like this:

Some Anonymous Poster: I'm trying to code some REXX panels in TSO and I can't figure out how this LISTCAT command is supposed to be working on my panel.

OK, confusion reigns. That's my point and why I am writing this column.

REXX is a programming language all on its own. It can (and frequently is) used with the ISPF API. But using ISPF is certainly not mandatory for REXX. REXX can run from the line-mode TSO READY prompt just as easily as a CLIST. REXX can run in batch. Heck, REXX can run on many operating systems, not just z/OS and mainframe TSO/ISPF.

REXX has a rich enough set of functions, I/O services and syntax such that entire systems could be written in it (although I can't recommend doing so on z/OS if high performance is required) without ever going near TSO/ISPF. Except to code it, of course. And even that is changing.

Conclusion
It's recap time.

TSO/E is an old-time networking system that constantly monitors all time-sharing system address spaces (TSO users). It has a complex command programming capability that is not for the feint of heart. For the vast majority of TSO/ISPF users, all they need to know is TSO is where you log-on to the system to get to?

ISPF, which sits on top of TSO and contains the crown jewel ? the editor. Since TSO is a prerequisite to launching ISPF, ISPF is also slavishly dependant upon the press of an AID key (so TSO will see it and take action). For the adventurous coder, ISPF offers a huge set of services that allows you to roll-your-own ISPF dialogs ? in ANY language you choose ? COBOL, Assembler, PL/I, C, Pascal, CLIST and oh yeah, REXX.

REXX is an excellent language for what the kids call RAD ? Rapid Application Development. It is also just fine to use for many scripting type functions on the mainframe that require some sort of "programming". REXX frequently serves as the language behind an ISPF dialog. I'd define this as: A REXX program that takes advantage of the ISPF API to do its job.

Does this sound about right?