MVS TOOLS AND TRICKS OF THE TRADE MAY 2001 Sam Golob MVS Systems Programmer P.O. Box 906 Tallman, New York 10982 Sam Golob is a Senior Systems Programmer. He also participates in library tours and book signings with his wife, author Courtney Taylor. Sam can be contacted at sbgolob@cbttape.org. Information about the CBT MVS Tapes can be found on the web, at http://www.cbttape.org. USING SYSPROG TOOLS WITH APP-PROG AUTHORITY Recently, somebody wrote to me, saying that he is an application programmer, and he was having trouble setting up some programmer tools from the CBT Tape collection, because he didn't have enough "authority". My contention is that there are a lot of tools he still can use, and that he shouldn't give up from trying. This month, we'll talk about how to set up many tools that can be useful for any programmer who works on an MVS system. Most of the tools we use, run either under TSO, or under ISPF under TSO, or they run as batch jobs. Many of these tools are in the form of load modules. Load module tools that run under raw TSO usually must be in a link list library or a STEPLIB library that is mentioned in the JCL of your TSO LOGON proc. We also run REXX- or CLIST-based tools. REXX or CLIST based tools run out of the SYSPROC or SYSEXEC DD concatenation of your TSO session. ISPF based tools, besides having CLISTs or REXX execs, may also have PANELS to be hooked into the ISPPLIB ddname, message members to go into ISPMLIB, tables to go into ISPTLIB or ISPTABL, skeletons to go into ISPSLIB, and possibly additional load modules that can go into ISPLLIB. My answer to the fellow who wrote me, is that in most shops, you have full update and alter authority for your own datasets. Therefore, if your tools don't have to run APF authorized, just put them into your own datasets, and include those datasets into the appropriate ddname concatenations of your own TSO session. ISPF DATASET CONCATENATIONS, REQUIRED AND OPTIONAL It is easy for you to display which datasets are associated to which ddnames that are allocated to your TSO session. The fastest way to do this, on any MVS system, is to use IBM's LISTA TSO command. The trick is to use LISTA with the proper sub-parameters. If you don't do so, LISTA will indeed show the datasets allocated to your TSO session, but it won't show which ddnames they are associated with. Type in: LISTA HISTORY STATUS SYSNAMES or LISTA HI ST SYSN for short. You'll get a list of datasets currently allocated to your TSO session, ordered properly, and under each ddname. ISPF, under TSO, requires particular ddnames to be allocated, in order to run. The capabilities and characteristics of your ISPF session will depend greatly on which datasets are allocated to these required ddnames. To picture this, you know that systems programmers and application programmers both run ISPF. But systems programmers usually can do far different actions than application programmers normally can do. That's largely because the datasets allocated to their ISPF sessions are different from those of the application programmers. The rest of the difference arises from security privileges and APF authorization, but you'd be surprised, as an application programmer, to know how much TSO and ISPF power is NOT dependent on those two things, but just on the contents of the allocated datasets. Now let's talk further about the ddnames needed for ISPF. Some of these ddnames are absolutely required; ISPF will not start if that ddname is not there. Others of the ddnames are optional. ISPF will start. But if these ddnames are not present, ISPF will not be able to use certain of its capabilities, which depend on thet particular ddname. Let's give examples of required, and optional, ddnames for ISPF. For example, the ISPPROF ddname, pointing to the ISPF profile dataset for your ISPF session, must be pre-allocated or ISPF will not start. On the other hand, the SYSPROC ddname, which points to libraries containing CLISTs or REXX execs, does not have to be present for ISPF to start. But there's one problem. If the SYSPROC ddname is not present, you won't be able to execute CLISTs or REXX execs from ISPF with just one command name. And the capabilities of your ISPF session will be severely limited, because many ISPF dialogs and applications require CLISTs or REXX execs, in order to run. Without accessibility to the SYSPROC libraries, you won't be able to do a lot of the things you want to, but ISPF will still initialize. Here's a list of required ddnames, which are necessary for ISPF to initialize. They are: ISPPROF (pointing to the profile dataset), ISPPLIB (pointing to your ISPF panel libraries), ISPTLIB (pointing to your ISPF table libraries - read only), ISPMLIB (pointing to your ISPF message libraries), and ISPSLIB (pointing to your ISPF skeleton libraries). I did an experiment, and found that the presence of all other ddnames, is optional for ISPF to initialize. Here are some optional ISPF ddnames: SYSPROC (to execute CLISTs or REXX execs), SYSEXEC (to execute REXX execs), ISPTABL (ISPF table libraries you want to write to), ISPLLIB (load libraries, to execute programs in non-authorized mode, from your ISPF session), SYSLBC, to point to the SYS1.BRODCAST dataset, and there are some others. Now let's get to the main point of this month's column: If you want to add new capabilities to your ISPF session, you must carefully control the contents of the datasets allocated to your ISPF session. But, if you complain that you are an application programmer, and your system administrators do not allow you to manipulate your session, we will show you where your degrees of freedom are. The truth is, that you can add a lot to your working environment, even if you are "just" an application programmer. YOUR OWN DATASETS Almost all shops will not restrict your access to your own libraries. This means that if you create a partitioned dataset with your own TSO id as its high-level qualifier, the shop will not stop you from updating or otherwise accessing its contents. There may be other restrictions the shop will impose--it may not grant update access to system libraries or APF authorized libraries. But these restrictions are OK. They are necessary, so that the application programmers will not (unknowingly or knowingly) update the system, and damage it. Most shops will let the application programmers "clobber" their own libraries, however, because application programmers are considered responsible enough to administer their own programs and materials. Therefore, you have freedom to get to work. You can allocate a set of libraries such as: yourid.ISPPLIB, yourid.ISPSLIB, yourid.SYSPROC, yourid.ISPLLIB, yourid.ISPTLIB, yourid.ISPMLIB, and perhaps a few others. Most shops will not restrict your capability to do that, except perhaps if you take too much disk space. You should be careful to take a little more than enough space, use sizable secondary extents, and to allocate enough directory blocks to allow for expansion. Once you've allocated your datasets, and even before you've put anything into them, you have to hook them into your TSO session, making them accessible to ISPF too. There are several ways to do this--each has advantages and disadvantages. It's nice to know some of the tricks. The straightforward way to hook your datasets into TSO and ISPF, is to re-do the exising dataset allocations, adding your own datasets to either the top, the middle, or the bottom of the concatenation for each ddname. For example, if your TSO session has ISPPLIB allocated to two datasets: SYS1.ISPPLIB and APPLIC.ISPPLIB, then you can hook yourid.ISPPLIB ahead of them, or behind them, using the TSO ALLOCATE command, as we'll describe. Please notice that if you use the SHR and REUSE parameters of ALLOCATE (REUSE was introduced with TSO/E), then you don't have to FREE the previous allocation for that ddname. You just have to write a CLIST to do the allocations, and you can execute the CLIST either invoking EXEC 'your.library(clisname)' under TSO, or if you already have the library containing your CLIST in the SYSPROC concatenation, you just have to enter %clisname as a TSO command. The allocation, if you want to concatenate your library ahead, is: ALLOC FI(ISPPLIB) SHR REUSE DA('yourid.ISPPLIB' + 'SYS1.ISPPLIB' 'APPLIC.ISPPLIB' ) This action can be done for all the libraries you need. Just include your own library or libraries, ahead or behind the rest. Then invoke ISPF, using its alias name ISPF, or its real name, ISRPCP. That's all there is to it. There's one more catch. This allocation must be done under raw TSO, before ISPF comes up. Many shops force the application programmers who logon to TSO, to go directly into ISPF, restricting their access to the "raw TSO" that lies beneath. ISPF will not allow you to reallocate its REQUIRED ddnames while it is running. But it will allow you to reallocate its OPTIONAL ddnames. And you can also invoke ISPF LIBDEFs under ISPF, to do some "temporary" modifications to ISPF required ddname allocations. So if you're in a shop that doesn't let you get into raw TSO, you can partially get around that restriction, by making a CLIST to reallocate the "optional" ddnames under ISPF, and to issue ISPEXEC LIBDEF commands to modify the "required" ddnames. Another thing you can do: Since ISPLLIB is not a required allocation for ISPF, you can reallocate ISPLLIB under ISPF to invoke any load modules you want to hook in to your session. And since SYSPROC or SYSEXEC are not required ISPF allocations, you can reallocate them too. Therefore, you have the freedom to hook in many REXX execs or CLISTs, which can perform system level functions. Or, from ISPLLIB, you can execute non-authorized TSO commands, such as the PDS command package from File 182 of the CBT MVS Utilities Tape collection. So despite a restriction on getting into "raw TSO", you still have much freedom to add a lot of new functionality to your session. MISCELLANEOUS TIPS There exist several programs on the CBT MVS Utilities tape collection, which allow you to automatically add or delete a library from a dataset concatenation under TSO. This is done, keeping the other libraries in the concatenation intact. The dataset concatenation program I tested was the KONCAT program on File 355, which worked well on my system. Other CBT Tape files which claim to contain concatenation programs or REXX execs, are files 134, 183, 270, 300, 357, 371, and 454. Please see Figure 1, for an example of a CLIST which invokes the KONCAT command and then invokes ISPF. Look at Figure 2, to see some of the options of the KONCAT command. Another tip: If you have a CLIST library called yourid.CLIST, and your TSO profile (not the ISPF profile) has your userid as a prefix, then you can invoke a CLIST out of this library, simply by enclosing its name in parentheses. Thus, if your CLIST name is XYZ, and it is a member of yourid.CLIST, you invoke it simply as (XYZ). Figure 3 is a simple CLIST which I've called IC, that invokes another CLIST in dataset yourid.CLIST, even if yourid.CLIST is not in your SYSPROC concatenation. Just say: IC XYZ , if XYZ is the name of your CLIST. You can put the IC clist in the SYSPROC concatenation, and use it to invoke other CLISTs that aren't in the SYSPROC concatenation. A third tip is to look at CBT Tape File 495, which comes from Tom Conley. Tom has a system to dynamically hook and unhook ISPF applications into your session. There's a gotcha or two, but Tom's system deserves a good look. I hope this month's topic was useful to all of you, and that it will help both systems programmers and application programmers alike. You should know that at one of the sites I access, I myself only have application programmer privileges. And I've even developed some system level tools there. You can accomplish a lot, wherever you are. Best of luck. I'll see you again next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. Invoking the KONCAT command to concatenate your own libraries to existing ddnames, and then start ISPF. This is a CLIST, which you can invoke from "raw TSO". KONCAT ISPPLIB 'MYUSRID.PANELS' KONCAT ISPMLIB 'MYUSRID.MSGS' KONCAT ISPSLIB 'MYUSRID.SKELS' KONCAT ISPLLIB 'MYUSRID.LOAD' KONCAT ISPTLIB 'MYUSRID.TABLES' KONCAT SYSPROC 'MYUSRID.CLIST' ISRPCP * * * * * * * * * * * * * * * * * * * * * * * Figure 2. Part of the TSO HELP member for the KONCAT TSO command from File 355 of the CBT MVS Tape. KONCAT will concatenate a specified data set either "BEFORE" or "AFTER" existing concatenations for the specified DD-name. )X SYNTAX: KONCAT DDNAME DSN BEFORE EVEN MSG NODEBUG AFTER ONLY NOMSG DEBUG REMOVE VERIFY Required - DDNAME, DSNAME Defaults - BEFORE, ONLY, NOMSG, NODEBUG )O OPERANDS - ))DDNAME - Data Definition Name to use for the concatenation. ))DSNAME - Data Set Name to be (re)allocated to the DDNAME. ))AFTER - Optional; allocate DSNAME after other data sets. ))BEFORE - Optional; allocate DSNAME before other data sets. ))EVEN - Optional; reallocate DSNAME to DDNAME even if it is already present. ))ONLY - Optional; allocate DSNAME to DDNAME only if it is not already present. ))MSG - Display ALLOC diagnostic messages. Default value. ))NOMSG - Disable "MSG" parameter. ))DEBUG - Show progress through KONCAT program. ))NODEBUG - Don't show progress through KONCAT program. * * * * * * * * * * * * * * * * * * * * * * * Figure 3. A simple CLIST, which I call "IC" that you can put in a library that is already in the SYSPROC concatenation, so it will invoke another CLIST in your yourid.CLIST library. PROC 1 NME EXEC (&NME)