
MainframeSupports tip week 19/2006:
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.
Previous tip in english
Sidste danske tip
Tip list
|