Command Table Overview

Traditional ISPCMDS
Text that is typed into the Command ==> field of any ISPF panel will always trigger a serial search of ISPCMDS. If an application command table is present, it too will be searched. The application table will be searched before ISPCMDS. For many years, individual sites and third-party software vendors have customized the baseline ISPCMDS. The customization consists of adding new rows at the end of the table. Then, the modified ISPCMDS is added to a PDS that is concatenated ahead of the IBM version at DD name ISPTLIB.

This works fine until a new release of ISPF is installed. Recent releases of ISPF have added many new commands to ISPCMDS. Also, some commands, like KEYLIST, have had their functionality changed.

If your ISPF users are getting a "COMMAND NOT FOUND" message when they try to use certain Action Bar choices, you have the backdated command table problem. Another symptom: Issue Command ==> KEYLIST OFF. If this command launches the KEYLIST utility, your ISPCMDS table is certainly out of date.

Pick your Fix
So how do you correct the problem? You have a choice:

1) Reapply your customization to the BASELINE ISPCMDS table.
2) Use one or both of the new command tables provided by IBM : USER and SITE.

Option 1 might be called the "quick fix". In an hour or two, you could probably correct the situation. Option 2 is really the way to go. IBM has recognized the need to provide an improved searching environment for ISPF command tables. It may take a little more research and planning to implement the new tables. However, it will forever eliminate the backdated ISPCMDS problem when new versions/releases are installed. This is why Option 2 is the preferred choice.

ISPF Option 3.9 - Command Table Utility
The Command Table Utility is really not meant to be used by all ISPF users. Most people ignore it. This is good. Ever since Version 4 of ISPF it has run in pop-up mode. It has a choice you may select to show the description field. But what is most interesting appears on the right-hand side of the pop-up window. You will notice that there are four possible command table prefixes shown. The first one should be ISR. The next 2, USER and SITE first appeared in Version 4. Finally, ISP is last. Read the text on the pop-up. It explains how the 1-4 character prefix (like ISP) is concatenated to the suffix "CMDS" to form the full table name. The order that the command table prefixes are shown on the screen is the search order. Remember this. It is VERY important.

Don't worry about the ISR table. You probably don't have one. IBM doesn't distribute one. The only reason that ISR shows up is because ISR is the NEWAPPL named on the standard IBM supplied ISPSTART commands. You know these by their SYS1.CMDLIB aliases: ISPF and PDF. The real SYS1.CMDLIB module name is ISRPCP.

If you enter ISP as the prefix at the 3.9 utility, you will be able to view the memory resident, always open, copy of ISPCMDS that was opened at initial subtask ATTACH time. A message is displayed that reminds you that you cannot change the ISPCMDS table here.

ISPF Configuration Table - Implementation
The USER and SITE tables names are added by declaring values for the APPLID_FOR_USER_COMMAND_TABLE and APPLID_FOR_SITE_COMMAND_TABLE variables in the ISPF Configuration Table. Try using the actual words: USER and SITE. People charged with testing the ISPF configuration should work with a load module that is link-edited at ISPLLIB. Once this is done, when ISPF is started from TSO, if there are tables at ISPTLIB named "USERCMDS" and/or "SITECMDS" they will be opened. If neither is present, no error occurs.

Creating a SITECMDS table
Here is a step-by-step process that you can use to create a SITECMDS table.

1. Determine exactly which commands have been added to ISPCMDS at your site in prior releases of ISPF. Have a list of them ready before beginning. You will need the ZCTVERB, ZCTTRUNC and ZCTACT at a minimum. You should also add the optional description column, ZCTDESC.
   
2. Go to the 3.9 utility. Use XXXX as the application id. If no XXXXCMDS table exists at ISPTLIB, you should be presented with an empty table. This is what you want. Before proceeding, make sure that the DD name ISPTABL is allocated. This DD name is where ISPF tables are saved. Note that ISPTABL is NOT a required ISPF DD name at initial subtask ATTACH time. However, it must be allocated prior to the ISPSTART from TSO. So, you may have to get to READY mode, allocate it and then get back into the ISPF 3.9 utility.
   
3. Add each command, truncation value, action and description on separate rows. When you have entered all of your site-specific commands, press PF3 (END) to save the XXXXCMDS table. If you get the "flowerbox error", issued by the Dialog Manager when a service return code greater than eight and CONTROL ERRORS CANCEL is active, most likely, it is because the ISPTABL DD name is not allocated.
   
4. If all goes normally, the XXXXCMDS table will be stowed into the PDS allocated at DD name ISPTABL. Note that ISPTABL is an output-only DD and should never contain a concatenation. Rename XXXXCMDS to SITECMDS using the appropriate ISPF utility.
   
5. Finally, move the newly renamed SITECMDS table into a PDS that is included in the ISPTLIB concatenation of ALL of your ISPF users.

ISPCMDS and SITECMDS: Before of After?
Another variable in the ISPF Configuration Table allows you to have the SITECMDS table searched last. BEFORE is the default. Remember, ISPF commands like SWAP, UP, DOWN, SPLIT are far more frequently executed than most site specific commands. I would recommend placing your SITECMDS table last. Use the SITE_COMMAND_TABLE_SEARCH_ORDER setting to accomplish this.

Conclusion
If you elect to use the new SITECMDS table AND you have an older, customized version of ISPCMDS around, don't forget to revert to the pure baseline ISPCMDS.

•
•
•
•
•
•

•