Debugging programs loaded from library lookaside (LLA)

z/OS® Debugger obtains information about programs in memory by using binder APIs. The binder APIs must access information stored in the data set containing the load module or program object. In most cases, z/OS can provide z/OS Debugger the data set name from which the program was loaded so z/OS Debugger can pass it to the binder APIs. However, z/OS does not have this information for programs loaded from LLA.

When z/OS Debugger attempts to debug a program loaded from LLA, z/OS Debugger does the following steps:
  • z/OS Debugger checks for the allocation of DD name EQALOAD and checks that it contains a member name that matches the program that LLA loaded.
  • If z/OS Debugger does not find a program by the specified name in EQALOAD, z/OS Debugger scans DDs on the program search path for a member name that matches the program that LLA loaded. The search path includes JOBLIB/STEPLIB and applicable task libraries.
  • If z/OS Debugger does find a program by the specified name in one of the previous steps and the length of this program matches the length of the program in memory, z/OS Debugger passes the name of the corresponding DD statement to the binder APIs to use it to obtain the information.
The following restrictions apply:
  • z/OS Debugger cannot always determine the exact length of the program in memory. In certain situations, the length might be rounded to a multiple of 4K. Therefore, the length checking is not always exact and programs that might appear the same length are not.
  • The copy of the program found in DD name EQALOAD or in a DD from the search path must exactly match the copy in memory. If the program found does not exactly match the copy loaded from LLA (even though the lengths match), unpredictable problems, including abends, might occur.