On Wed, 17 Dec 2025 17:59:14 +0100, Radoslaw Skorupka <[email protected]> wrote:
>It is not me who used binder improperly. Or messed order of activities. It was the developer who messed up. They created the SMP/e definitions and you don't have any control over this. UCLIN (not ++x) is your only control to SMP/e definitions. It was not my intention to blame you. >However I dare to disagree. It is matter of SMP/E logic. >Same tool (binder), two different SMP/E >command sets which *should* yield same result. But the results differ. The goal of SMP/e is to "yield the same result" but it does not make this guarantee. As developers, we use SMP/e to help us make this guarantee. SMP/e has utilities and each developer must use these utilities so the results will always be the same regardless of how many FMID's and PTF's. Consider the SMP/e Unix utilities (specifically scripts). SMP/e has no control over scripts and cannot make any guarantee the developer coded the script correctly. Likewise, SMP/e does not control nor limit how I use the binder. I should never use CALL instead of NCAL but it's my choice. Same with INCLUDES inside of INCLUDES. I can have multiple CSECTS in a single object. And much more. If I use any of these features, it is my responsibility to convey this correctly to SMP/e to guarantee the same results no matter how the customer applies PTFs, APARs & FMIDs. You've mistaken SMP/e convenience tools (designed to make developer's lives much easier) as SMP/e binder commands. They are very basic and minimalistic. Consider a ++MOD (object file) that contains multiple CSECTS. JCLIN does not see the CSECTS in the ++MOD because all binder compatible formats are allowed. Since JCLIN for INCLUDE statements build a MOD entry with a matching CSECT, it is up to the developer to tell SMP/e about the other CSECTS. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
