For all kinds of ISPF programmers and mainframe software vendors the LIBDEF function is an almost unescapable part of life. Unfortunately LIBDEF causes a lot of grief. With this tip I will try to relief your pain.

If you do not know the LIBDEF function already, I can tell you that LIBDEF is a way to allocate more datasets to the concatenation of ISPF system datasets like ISPPLIB, ISPLLIB and others. These extra allocations will be put up front in the concatenation. LIBDEF gives you the advantage of allocating datasets containing panels, load modules and more that exactly matches the needs of your application. Problems caused by LIBDEF arises when you execute commands on top of each other in the same split screen or if an application forgets to deactivate LIBDEF concatenations. More complications arises because you can have different application Id's in the same split screen session. Within the same split screen session LIBDEF will overwrite a previously executed LIBDEF of the same type.

Until now I have just scratched a little bit in the surface of the problems. Help for many of the problems has been available through the STACK option for LIBDEF for some time. Another helping hand is the ISPF command ISPLIBD. ISPLIBD shows you the current LIBDEF definitions for the split screen and the application Id you are executing in. ISPLIBD is a simple tool, but very handy when you get into LIBDEF hell.

To avoid problems with the LIBDEF function I will suggest that you follow these rules. Firstly always remember to deactivate a previously activated LIBDEF. Secondly always use the STACK option on your LIBDEF. Thirdly avoid using options LIBRARY and EXCLLIBR. Here is an example of how to use LIBDEF in the most ideal way:

/* REXX: GOODDEF */
ADDRESS ISPEXEC
"LIBDEF ISPPLIB DATASET ID('MY.PANEL.DATASET') STACK"
"DISPLAY PANEL(MYPANEL)"
"LIBDEF ISPPLIB"

This GOODDEF REXX will show you the panel MYPANEL if it is defined correct and is located in dataset MY.PANEL.DATASET. This will also happen if GOODDEF did not include STACK on the first LIBDEF. Unfortunately a missing STACK option will cause a LIBDEF executed before GOODDEF were called, to be lost and most likely this will cause problems when the caller of GOODDEF regains control. IBM tried to solve this problem by introducing the COND option. If STACK is replaced by COND in GOODDEF then a previously executed LIBDEF will not be lost. Instead DISPLAY will fail if MYPANEL only exists in MY.PANEL.DATASET, because COND only executes the LIBDEF if no active LIBDEF exists for the specified type.

The last LIBDEF in GOODDEF deactivates the latest executed LIBDEF and in our example it is the LIBDEF of MY.PANEL.DATASET. If a LIBDEF was executed prior to the call of GOODDEF, then it becomes active again. If COND had been used instead of STACK then a previously executed LIBDEF outside GOODDEF would have been deactivated and this would not be a good idea.

Let me show you another example:

/* REXX: BADDEF */
ADDRESS TSO "ALLOC FI(MYPANELS) DA('MY.PANEL.DATASET') SHR REUSE"
ADDRESS ISPEXEC
"LIBDEF ISPPLIB LIBRARY ID(MYPANELS) STACK"
"DISPLAY PANEL(MYPANEL)"
"LIBDEF ISPPLIB"

In this example I execute an allocation of a DD name to MY.PANEL.DATASET and I use this DD name instead of letting LIBDEF execute the allocation. The sad thing about BADDEF is that DD name MYPANELS will be opened and remain open while displaying MYPANEL. The consequence is that if I try to execute BADDEF from another split screen meanwhile then BADDEF will fail. This will not happen in GOODDEF because ISPF is in charge of the allocations.

Here is a link to LIBDEF in one of the more recent versions of ISPF.