Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Thanks for catching that omission Peter. I wish I could edit my post... instead I'll just reposting that paragraph in hopes it's less confusing for anyone looking at the archives: The binder will simply discard the "private code" (unnamed) CSECT (section), if it has no text. It never gets incorporated into the module being bound, so it should have no effect on it. Binder has behaved like this since near the beginning (early 90's, around when PM3 format was introduced). On Peter Relson wrote: > Reply > > >The binder will simply discard the "private code" (unnamed) CSECT > (section), if it has text. > I suspect that Barry inadvertently omitted the word "no" before "text". > > Peter Relson > z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
>The binder will simply discard the "private code" (unnamed) CSECT (section), if it has text. I suspect that Barry inadvertently omitted the word "no" before "text". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Barry Lichtenstein wrote: The binder will simply discard the "private code" (unnamed) CSECT (section), if it has text. It never gets incorporated into the module being bound, so it should have no effect on it. Binder has behaved like this since near the beginning (early 90's, around when PM3 format was introduced). Thanks Barry! My casual tests did show that the binder does not ignore the AMODE of "private code" sections when they have text: DC 'Some text' AMODE 31 RMODE ANY FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END FOO will generate an AMODE 31/RMODE ANY load module, but DC 'Some text' AMODE 24 FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END FOO seems to an AMODE 24/RMODE 24 load module... but, AMODE 24 FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END FOO seems to generate an AMODE 31/RMODE ANY load module. - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
The binder will simply discard the "private code" (unnamed) CSECT (section), if it has text. It never gets incorporated into the module being bound, so it should have no effect on it. Binder has behaved like this since near the beginning (early 90's, around when PM3 format was introduced). The difference between the AMODEs is described in 'SYS1.MACLIB(IEWBCES)', which shows that X'00' is Unspecified while X'01' is explicitly AMODE=24. I believe this is from the days before there were AMODEs and RMODEs, perhaps some concern that Unspecified would have to be treated specially, though I'm not aware that it ever is. The treatment of AMODE & RMODE by the binder is described in the Program Management User's Guide and Reference in the Chapter "Creating programs from source modules", section "Addressing and Residence modes". As well of course under their respective options. Careful looking at the description of "Linkage Editor" processing, which is specifically talking about the very old linkage editor, which you'd only get with a few names such as HEWLKED. That's not the binder, it's talking about some of the usually not problematic differences. (Most everything uses the binder. SMP/E always uses the binder, never the linkage editor.) On Wed, 3 Feb 2021 11:57:07 -0500 Thomas David Rivers wrote: > > > > > I could find nothing in the "Program Management: Advanced Facilities" > > doc that indicated an AMODE flag value of B'00' is any different/special > > verses B'01' (it is surprising that there are 2 AMODE 24 options there.) > > I _did_ find a parenthentical comment in the book "z/OS MVS Programming: > Assembler Services Guide", in the section titled "Linkage editor > and binder support of AMODE and RMODE", in the sub-section of > "Linkage editor RMODE processing". It says: > >The linkage editor determines the RMODE of each CSECT. If the RMODEs >are all the same, the linkage editor assigns that RMODE to the load > module. >If the RMODEs are not the same (ignoring the RMODE specification on > common >sections), the more restrictive value, RMODE 24, is chosen as the > load module's RMODE. > > > So - it seems any RMODE specification on a common section (empty or not, > I suppose) > is ignored. > > I didn't (yet) find a similar statement about AMODE... > > Just wanted to leave this here for the future. > >- Dave R. - > > -- > riv...@dignus.comWork: (919) 676-0847 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Paul G wrote: Consider possible consequences when a program object is relinked of: XCSECT DCA(B) CSECT BDCH'0' END Assemble it; study the Relocation Directory; and weep. The assembly shows one RLD entry. I did not try to "study" it. -- When bound into a PDS, this loads fine. -- When bound into a PDSE, this loads fine. -- When rebound from the PDSE into the same PDSE, this loads fine. I'll bite. What's untoward about this? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Thomas David Rivers wrote: I could find nothing in the "Program Management: Advanced Facilities" doc that indicated an AMODE flag value of B'00' is any different/special verses B'01' (it is surprising that there are 2 AMODE 24 options there.) I _did_ find a parenthentical comment in the book "z/OS MVS Programming: Assembler Services Guide", in the section titled "Linkage editor and binder support of AMDOE and RMODE", in the sub-section of "Linkage editor RMODE processing". It says: The linkage editor determines the RMODE of each CSECT. If the RMODEs are all the same, the linkage editor assigns that RMODE to the load module. If the RMODEs are not the same (ignoring the RMODE specification on common sections), the more restrictive value, RMODE 24, is chosen as the load module's RMODE. So - it seems any RMODE specification on a common section (empty or not, I suppose) is ignored. I didn't (yet) find a similar statement about AMODE... Just wanted to leave this here for the future. - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
On Tue, 2 Feb 2021 17:01:20 -0500, Thomas David Rivers wrote: >>... >Someone kindly pointed out this documentation from the HLASM Language >Reference about how/when these unnamed/empty PC sections get created: >... > An unnamed control section is sometimes referred to as private code. > Private code sections are sometimes difficult to manage with other > system components such as linkers and configuration management tools. > (Such as SMP/E, which just accumulates them with each PTF.) > Avoiding their use is recommended. (Zero-length private code sections > are sometimes ignored or discarded by system linkers.) > Consider possible consequences when a program object is relinked of: XCSECT DCA(B) CSECT BDCH'0' END Assemble it; study the Relocation Directory; and weep. A generally expert co-worker introduced an unnamed CSECT to suppress a base register warning. I suggested using the "limit" on USING. She considered it to avant-garde (i.e. she had never done it before) and just gave an name to the second CSECT. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Thomas David Rivers wrote: I could find nothing in the "Program Management: Advanced Facilities" doc that indicated an AMODE flag value of B'00' is any different/special verses B'01' (it is surprising that there are 2 AMODE 24 options there.) Someone kindly pointed out this documentation from the HLASM Language Reference about how/when these unnamed/empty PC sections get created: The unnamed section is an executable section that can be initiated in one of the following two ways: - By coding a START, CSECT, RSECT, or COM instruction without a name entry - By coding any instruction, other than the START, CSECT, or RSECT instruction, that initiates the first executable section An unnamed control section is sometimes referred to as private code. Private code sections are sometimes difficult to manage with other system components such as linkers and configuration management tools. Avoiding their use is recommended. (Zero-length private code sections are sometimes ignored or discarded by system linkers.) The keyword here is "sometimes ignored or discarded". In playing around with this a little, I couldn't get the binder to do anything _but_ ignore it. If you take, for example, this ASM source: X EQU 1 FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END you'll get that wonderful zero-length PC section with a flags field of X'00'. But, the resulting load module (with no AMODE/RMODE options specified on the binder) is AMODE 31/RMODE ANY. If you instead do this: X EQU 1 AMODE 24 FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END you still get the unnamed zero-length PC section, but the flags field will be X'01' (explicitly indicating AMODE 24.) However, again without specifying any binder options, the resulting load module is AMODE 31/RMODE ANY. So - it _seems_ the binder simply ignores these zero-length unnamed sections with regard to the resulting AMODE/RMODE values for the load module. The word "sometimes" in the HLASM documentation is, well, less-then-precise. I'm still looking for some precision on just which linkers/binder do and don't ignore the unamed zero-length section, and which attributes may or may-not be considered. Just thought I'd throw out what my empircal testing has shown to date; this is on z/OS 2.4. - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Binyamin Dissen wrote: How would a zero length CSECT be placed in a load module? It doesn't take up any space - so it would just be given the next offset, a following CSECT would be placed at the same offset I assume. The question really is, do any of the other attributes associated with such a CSECT (in particular the AMODE/RMODE attributes) affect the resulting load module (or program object.) If you had, for example: CSECT AMODE 24 PROG CSECT PROG AMODE 31 BR 14 END PROG and didn't specify any particular AMODE/RMODE options on the linker/binder, what would the resulting AMODE/RMODE of the load-module be? And, even more interesting is "why". Does the empty CSECT contribute to that decision, or is it dismissed because it is empty? I couldn't find anything in the doc that would indicate its dismissed, but I think it might be... I believe some experimentation is in order. If I determine the behavior today, without documentation indicating that, it seems it's free to change in the future. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
On Tue, 26 Jan 2021 17:35:12 -0500 Thomas David Rivers wrote: :>Sometimes, it seems pretty easily, the output of HLASM :>will include a zero-length PC (Private CSECT) section with :>a valid of X'00' for the FLAG field, as evidenced from both :>the HLASM listing and the ESD data in the ESD card of :>the output file. :>This can happen quite by accident and is clearly unintentional, :>but it seems to be quite benign. Most annoying as it happens when EQUates are used before a CSECT declaration. I have no clue why an EQU requires a containing CSECT. Therefore I do not place EQUs at the front of a program. :>The flags field of a PC entry defines the AMODE and RMODE :>for the CSECT. AMODE is documented as being AMODE 24 :>if the lower bits are B'00' _or_ B'01'. In this case, they would :>be B'00'. And the RMODE would be 24. :>If I have such an AMODE24/RMODE 24 for a PC entry, I would expect the :>resulting load module to be AMODE 24/RMODE 24 after binder processing; :>but it doesn't appear to be so. :>I could find nothing in the "Program Management: Advanced Facilities" :>doc that indicated an AMODE flag value of B'00' is any different/special :>verses B'01' (it is surprising that there are 2 AMODE 24 options there.) :>So - my questions are this, and perhaps some binder aficiandos can :>answer them: :> 1) Is the AMODE specification of B'00' "special" in some way, vs. the :> presumably equivalent specification of B'01'. :> 2) Does the binder ignore zero-length CSECTs when determining :> the resulting AMODE and RMODE of the result load module? :> (That would make some sense, but I couldn't find a statement :> to that effect.) Seems like the "older" linkage-editor would :> need the same requirement. How would a zero length CSECT be placed in a load module? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zero-length PC section, the binder, and resulting AMODE/RMODE
Sometimes, it seems pretty easily, the output of HLASM will include a zero-length PC (Private CSECT) section with a valid of X'00' for the FLAG field, as evidenced from both the HLASM listing and the ESD data in the ESD card of the output file. This can happen quite by accident and is clearly unintentional, but it seems to be quite benign. The flags field of a PC entry defines the AMODE and RMODE for the CSECT. AMODE is documented as being AMODE 24 if the lower bits are B'00' _or_ B'01'. In this case, they would be B'00'. And the RMODE would be 24. If I have such an AMODE24/RMODE 24 for a PC entry, I would expect the resulting load module to be AMODE 24/RMODE 24 after binder processing; but it doesn't appear to be so. I could find nothing in the "Program Management: Advanced Facilities" doc that indicated an AMODE flag value of B'00' is any different/special verses B'01' (it is surprising that there are 2 AMODE 24 options there.) So - my questions are this, and perhaps some binder aficiandos can answer them: 1) Is the AMODE specification of B'00' "special" in some way, vs. the presumably equivalent specification of B'01'. 2) Does the binder ignore zero-length CSECTs when determining the resulting AMODE and RMODE of the result load module? (That would make some sense, but I couldn't find a statement to that effect.) Seems like the "older" linkage-editor would need the same requirement. - Many thanks! - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
