Customizing Your ISPF Environment
This article will show you how to customize your ISPF environment. To start, let’s dive in to some commands we’re going to need, specifically the ALTLIB and the LIBDEF commands.
Note: This is the second article in a two-part series. The first appeared in the July/August issue.
The previous article in this series covered what makes up a Time Sharing Option (TSO) session and how one is commonly implemented. Every mainframe implementation in the real world is different. Some differ wildly, while others require just minimal changes to a CustomPac installation to ensure the customer-application continuity and the other layers above the OS level.
Usually part of the customization made to the supplied z/OS* interfaces is the addition of local logon procedures and Clist or REXX logon scripts. The main Interactive Systems Productivity Facility (ISPF) panel is also usually changed, adding menu options for local applications or products. At the end of the previous article, I left you with the task of finding your local logon script, starting with your logon procedure. How'd that go?
This article will show how to customize your ISPF environment. To start, let's dive into some commands we're going to need, specifically the ALTLIB and the LIBDEF commands.
ALTLIB and LIBDEF Commands
We're going to use the ALTLIB command (see "Links," at the end of this article) to add a partitioned data set containing REXX source code to our current concatenation. Remember that the list of data sets searched whenever a command is issued is built for us by our local systems programmer and embedded in the logon procedure or logon script (REXX or Clist). In most cases you won't have the necessary security privileges to update these system-level scripts (nor should you), so your only choice is to add your scripts in addition to these, or override the provided concatenations somehow if you want to change the default behavior. This is where ALTLIB comes into play.
The other command we need to help override the provided concatenations is the LIBDEF command, the URL to which can also be found in the Links section. A significant difference between these two commands is that ALTLIB can only update or change the data sets involved in calling a REXX or Clist script. Whereas the LIBDEF applies to the set of concatenations involved in the ISPF environment and can update all of these, LIBDEF can't be used to do anything with your REXX or Clist data set concatenations.
Up to this point, we've primarily focused on TSO and what makes up a TSO session. Before we go any further it's necessary to have some background on what makes up an ISPF environment.
ISPF is responsible for providing the screens, messages and other components that make up the normal mainframe working environment. As such, ISPF is actually written using ISPF - more precisely, ISPF uses the ISPF dialog services to present the environment we know of as ISPF itself.
I mentioned screens and messages above, but a few other components of ISPF are worth knowing. Table 1 shows these and I explain them later.
Other DDs in addition to these listed are also required for full ISPF services exploitation but are beyond the scope of this article. The use of panels is perhaps the most obvious. These are the screens you actually interface with when using ISPF. They're written using a special screen definition language not too dissimilar (in concept if not implementation) to the tag-based markup Web language, HTML.
Messages are also fairly obvious. Press PF1 (F1 on PC keyboards) whenever a short message appears in the upper right hand corner of your ISPF screen and if the application developer supplied one, you'll be shown the matching "long message." These messages are stored in the datasets allocated to the ISPMLIB DDname and are presented by the ISPF application - assuming the programmer provided the necessary error-checking code - when errors are trapped or information messages are required.
Skeletons are a highly flexible feature of the ISPF dialog development environment. They allow you to have code (or any text for that matter) defined as a template, which can then be processed before being used. The processing can include logic (i.e., select or discard a portion of the template) based on environment variables that may have been influenced by the user as they progress through the particular ISPF dialog.
Tables are quite familiar to all ISPF users although you may never have realized it. ISPF option 3.4 (DSLIST) is a great example of the use of tables in ISPF dialog development. Tables provide services to the dialog developer that handle things like scrolling, selecting multiple rows for processing and generally managing lists of items to be displayed one item per line. You can see that the ISPF option 3.4 is actually just a variable-length list of datasets. The DSLIST dialog uses ISPF table processing to both generate the screen and manage the basic user interaction with screen line items (i.e., datasets in this example).