Re: SMP/E vs. Multi-CSECT MOD Elements?
On 12/2/2011 12:05 PM, Paul Gilmartin scratched his head and wrote: If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this is done (in a warning, as if it were an extraordinary occurrence). Yes, the APPLY will generate REPLACE statements so the binder can delete the omitted CSECTs. If I RESTORE to the earlier version, does SMP/E put such CSECTs back? Where does it get them? The DLIB? SMP/E includes the MOD from the DLIB, so if the accepted level of the MOD has those CSECTs, then they will be added to the LMOD. 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.) Similar to APPLY, yes RESTORE should generate the appropriate REPLACE statements so the binder can delete the proper CSECTs. In the extreme, what happens if two or more MOD elements contain an identical CSECT? Without a more specific description of the scenario its hard to say, but as you surmise, this could get interesting. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
On 12/2/2011 12:05 PM, Kurt Quackenbush wrote: quote If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this is done (in a warning, as if it were an extraordinary occurrence). Yes, the APPLY will generate REPLACE statements so the binder can delete the omitted CSECTs. /quote How will APPLY know to replace (i.e. delete) the unreferenced CSECT's? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
On Mon, 5 Dec 2011 10:02:00 -0600, Staller, Allan wrote: How will APPLY know to replace (i.e. delete) the unreferenced CSECT's? When a SYSMOD includes a ++MOD that specifies the CSECTS that are included in that MOD, and another SYSMOD provides a replacement ++MOD that has a different list of CSECTS specified, SMP/E knows that there is a difference. This is not the same as providing a ++MOD that contains multiple CSECTS and not telling SMP/E about them. In that case, SMP/E would not know. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
If I APPLY a MOD that has fewer CSECTS than an earlier version, are the omitted CSECTs REPLACEd? The Reference implies that this is done (in a warning, as if it were an extraordinary occurrence). Yes, the APPLY will generate REPLACE statements so the binder can delete the omitted CSECTs. How will APPLY know to replace (i.e. delete) the unreferenced CSECT's? Consider the following: ++PTF(P1). ++VER ... ++MOD(A) CSECT(FOO,BAR). ++PTF(P2). ++VER ... PRE(P1). ++MOD(A) CSECT(FOO). SMP/E compares the CSECT lists for module A between the two PTFs and knows to delete BAR. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMP/E vs. Multi-CSECT MOD Elements?
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E vs. Multi-CSECT MOD Elements?
Comments indented. HTH, 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). No. The omitted CSECTS are still present. SMP works by including new CSECTS ahead of the existing LMOD. The L-Editor/Binder does the rest. IIRC, first occurrence of X wins. You will need to add replace statements for the omitted CSECTS and specify NCAL for the binder via a JCLIN to eliminate the deleted CSECTS.. The JCLIN will need to contain all of the explicit statements to build the new LMOD. You could probably accomplish the same thing w/UCLIN, (DEL MOD(x) LMOD(y). ??) but it seems like it would be harder get this right than to justreplace the necessary instructions to SMP/E. If I RESTORE to the earlier version, does SMP/E put such CSECTs back? Where does it get them? The DLIB? Yes. I believe it also gets the appropriate JCLIN from the DLIB version.. I am sure someone will correct me if this is not the case. If I APPLY a MOD that has more CSECTs than the earlier version, there should be no problem. Correct 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.) I do not believe so. See above. IIRC, the RESTORed LMOD will be built from the appropriate DLIB elements and JCLIN). 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?) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
