Hunting down references to unresolved symbols

Unresolved requests generate error or warning messages in the binder listing. If a function or variable is unresolved at the end of binder processing, it can be resolved at a later rebind.

Example: If you did not expect a symbol to remain unresolved, you can look at the binder listing to see which parts reference the symbol. If your DD SYSLIN has a large concatenation, the input is logically concatenated before the binder processes it. Since the compile units are not logically separated, it is hard to tell which compile unit defines the part that has the reference; for example:
  //SYSLIN DD DISP=SHR,DSN=USERID.PLAN9.OBJ(MEM1)
  //       DD DISP=SHR,DSN=USERID.PLAN9.OBJ(MEM2)
  //       DD DISP=SHR,DSN=USERID.PLAN9.OBJ(MEM3)
Example: You should consider using multiple INCLUDE control statements, which will logically separate the compile units for the binder informational messages in the listing. You can then find the compile unit with the unresolved reference (similar to finding duplicate function definitions); for example:
  //INOBJ  DD DISP=SHR,DSN=USERID.PLAN9.OBJ
  //SYSLIN DD *
   INCLUDE INOBJ(DOIT1)
   INCLUDE INOBJ(DOIT2)
   ENTRY CEESTART
  /*