Find what each load module is built from

Report what the binder puts in each load module and mark every deck and listing that says so: the program the module is named for, the subroutines and map sets bound in with it, where control enters, the other names it answers to, the step that links it and the steps that run it. Nothing in the COBOL or the JCL carries this — a step names a module and gets whatever was last bound into it — so a statically called subroutine is felt by every module holding a copy and by nothing else. The link-edit deck and the module listing are reconciled against each other, which is what separates a module that has drifted from its deck from one whose listing is simply older than the last build. AnalyzeLoadModuleComposition answers the same question and changes nothing.