Many versions and years ago something called KEYLISTS was introduced in ISPF. Most of us has ever since felt that KEYLISTS were implemented to make our ISPF life even more complicated. About four years ago I did not know anything about KEYLISTS except the command KEYLIST OFF. This command effectively disables KEYLIST functionality in ISPF. For more than four years ago I felt that some day I would find some kind of reasonable use for KEYLISTS.
Often I need to assign special values to F-keys on my ISPF panels. Traditionally I save the current value of a function key, assign it a new value and at the end of the application I reinstate the saved value. This approach has a drawback; if users activate other ISPF functions from my panel, the new F-key value is inherited by the activated functions. In other cases an ISPF abend occurs in my application and the new F-key value survives the crash instead of the original one. This is very annoying for the users.
The ideal situation is of course to have function key values that are related to the ISPF panel and nothing else. This is exactly what you can do with KEYLISTS. You can also do a lot of other stuff with KEYLISTS which will turn your ISPF life into hell. This tip is only dealing with a method that may be used to assign specific function key values to specific function keys on a specific panel using KEYLISTS.
A KEYLIST that users have in common is called a SHARED KEYLIST. Such a KEYLIST must be stored in the ISPTLIB concatenation. The following REXX creates an ISPF table containing a KEYLIST called MYKEYS. An ISPF table must have a name ending with KEYS to be considered a KEYLIST:
For each function key the column KEYxDEF is assigned the value of the function key, KEYxLAB is assigned the text that is displayed when PFSHOW is ON and KEYxATR is assigned a value telling ISPF how to display the KEY when PFSHOW is ON. Only function keys where KEYxATR is assigned the value LONG or SHORT is displayed. I have left out the assignment of keys 13 to 24. It is your job to add them. If you do not assign any values to these keys they cannot be used at all. Every time you run this REXX you will replace the existing ISPF table MYKEYS in the dataset allocated to DD name ISPTABL. It is possible to have more than one KEYLIST in the same ISPF table but I have chosen only to have one called MYKEYS just like the name of the ISPF table. It is column KEYLIST that contains the name of the KEYLIST.
To make a KEYLIST available for other users you must copy it to one of the datasets on the ISPTLIB concatenation that the other users also has allocated to their ISPTLIB concatenation. Now all you need to use your KEYLIST is to add the following line on top of your ISPF panel:
The ISPF panels where you add the above line will use the function key values that you gave them in your REXX. The parameter MYKEYS is the name of the KEYLIST that must be used on the panel. MY is the name of the ISPF table where the KEYLIST must be located. MY is concatenated with KEYS giving MYKEYS as the ISPF table name. Parameter SHARED indicates that it is not possible to edit the function key values using KEYS. SHARED also disables the possibility of using socalled PRIVATE KEYLISTS. With SHARED you effectively prevent any kind of changes to the values of the function keys on a specific ISPF panel while other ISPF panels and function key values remains unaffected. This was just what I wanted to acheive. Now I have put an end to the old behaviour of saving and restoring function key values.