On Sat, 2 Dec 2023 at 13:13, João Reginato <jb.regin...@gmail.com> wrote:
> Sorry guys > my poor english may be causing misunderstanding. > Perhaps, but it's a lot better than my Portuguese. I think we can understand it pretty well. :-) > You're right, TPUT doesn't use DCB and doesn't need RMODE 24 neither. > I don't know where I read it. > TPUT used to support only 24-bit mode, and I believe that was true in MVS XA and maybe later. But it's supported 31-bit mode for a long time now. > But I'm talking about change RMODE during the compilation time, before the > binder. > > Imagine a pgm that uses many macros and it may need or not "RMODE 24", > depending on some parms. > 1) The first macro sets "RMODE ANY". > 2) Then calls macro2, macro3 and so on. > 3) Suddenly, macroN uses a DCB for example, that must be defined as RMODE > 24. > 4) So, at this time, I want to set "RMODE 24" but the HLASM compiler sends > that error message. > 5) And the binder will use RMODE ANY from the macro1, wrongly. > Ah, it's beginning to make sense to me. Your original complaint was that you were receiving message "ASMA186E AMODE/RMODE already set for this ESD item". And that was true. Each section (normally CSECT, but also including RSECT, COMMON, and unnamed section) has exactly one RMODE setting (and of course there are defaults for these things). But you can assemble multiple sections in a single assembly, and each can have a different RMODE. (This is the SPLIT RMODE that Ed was referring to.) The RMODE instruction requires a lable that has to match the label on a CSECT or other section definition assembler instruction. You can define the RMODE for a section only once. If you want to, as you say, put a DCB into 24-bit storage, it needs to reside in a separate section from your 31-bit code. And at run time you will have to figure out to establish addressibility to that section, which - if you bind things appropriately - will be "split", i.e. by definition will not be right next to your RMODE 31 section. The RMODE instruction just marks each section in the object output. The binder, and z/OS at module load time, do the rest. So I need to prevent it resetting RMODE DURING THE COMPILATION TIME, before > the binder run. > It's rather more complicated than that. For something like a DCB in an otherwise RMODE-31 module, I would (as someone else suggested) just GETMAIN a piece of 24-bit storage and put it there dynamically. OPENing a DCB that is in the same section as your program code is inherently not reenterable, so it's generally a bad idea even if you figure out how to have multiple sections with different RMODEs. Tony H.
