I am struggling with an ISV compiler that delights in producing multi-CSECT MOD elements. I've never needed to put a CSECT list in ++MOD MCS previously, but now I see that I need to. So, I wonder:
If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this done (in a warning, as if it were an extraordinary occurrence). If I RESTORE to the earlier version, does SMP/E put such CSECTs back? Where does it get them? The DLIB? If I APPLY a MOD that has more CSECTs than the earlier version, there should be no problem. When I RESTORE, does it REPLACE the additional CSECTS? (I seem to see this happening when I RESTORE a PTF that introduced an new MOD element; that's where I went wrong by not supplying a CSECT option -- not all CSECTS were REPLACEd, and the stragglers caused Binder errors.) In the extreme, what happens if two or more MOD elements contain an identical CSECT? I can envision this happening without being a coding error if multiple assemblies need to COPY a SYSLIB definition of a data CSECT in order to know offsets -- when the load module is bound it doesn't matter which one is INCLUDEd -- all subsequent duplicates will be eliminated. (Yah, I know; it might be better to assemble it as a DSECT and deliver it as a separate MOD element. But isn't the rogue behavior endemic in C++ compiler output?) <WHINE> I wish SMP/E itself would scan the MOD elements to enumerate CSECTs, rather than placing the burden on the product developer, even as SMP/E scans inline assembler source for macro dependencies. Yah, I know; this would be easier for inline MOD elements than for RELFILE mod elements. </WHINE> Thanks, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
