What AMBLIST does, and all it does, is make IDRs (IDentification Records)---They are generated by the binder in response to IDENTIFY statements in its input stream---available.
If a compiler propagates information about the options that were used in a compilation, AMBLIST makes it available. If not, not. Most current IBM translators do propagate this information, together with a product identification, version and modification level, and translation date; and the binder does the same thing for itself What I should perhaps have mentioned in my original post is that these IDRs are different for load modules and program objects. Multiple IDRs for a CSECT, RSECT or COMMON section are not supported for load modules. They are supported for program objects. User data may be at most 40 bytes in length in load-module CSECT IDRs and at most 80 bytes in length in program-object CSECT IDRs. Worth noting while I am in pedagogue mode is that users are free to generate IDRs too, one for each load-module CSECT and many of them for each program-object CSECT. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
