RES: RES: Reseting RMODE
I got it. This was my idea for just testing programs during debugging. The macro simply reset rmode to 24 instead of getmain etc etc This way the binder links it rmode 24. As you said "The RMODE instruction just marks each section in the object output", It could just remark that section in the object output, before passing it to the binder. Anyway, thank you all for the answers. Regards João -Mensagem original- De: IBM Mainframe Assembler List Em nome de Tony Harminc Enviada em: sábado, 2 de dezembro de 2023 15:49 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: RES: Reseting RMODE On Sat, 2 Dec 2023 at 13:13, João Reginato 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.
Re: RES: Reseting RMODE
I generally allocate a work area that begins with a save area and do an MVCL that includes every DCB, DCBE and MF=L macro, then do a cleanup of pointers that I can't set with MF=E. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Tony Harminc Sent: Saturday, December 2, 2023 1:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: RES: Reseting RMODE On Sat, 2 Dec 2023 at 13:13, João Reginato 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.
Re: RES: Reseting RMODE
On Sat, 2 Dec 2023 at 13:13, João Reginato 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.
RES: RES: Reseting RMODE
Sorry guys my poor english may be causing misunderstanding. You're right, TPUT doesn't use DCB and doesn't need RMODE 24 neither. I don't know where I read it. 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. So I need to prevent it resetting RMODE DURING THE COMPILATION TIME, before the binder run. I hope it helps TIA João -Mensagem original- De: IBM Mainframe Assembler List Em nome de Steve Smith Enviada em: sábado, 2 de dezembro de 2023 12:00 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: RES: Reseting RMODE This conversation is making less and less sense. Since when does TPUT use a DCB? On the original question: RMODE sets a flag on the module that ultimately tells program fetch to load your program above or below the line (or bar, these days). Once loaded, what do you expect to happen on an RMODE change? You want program fetch to somehow delete the above the line copy and reload it below? Sorry, but that's ridiculous. If you think your code needs to be RMODE 24 for any reason, then it must be always. sas On Sat, Dec 2, 2023 at 5:48 AM João Reginato wrote: > I use TPUT sometimes as a trace tool only and it uses a DCB that must be > below the line. > As I just use it in debugging situations, and inside a macro, that was > easiest to me do this way. > But the discussion is not the TPUT but RMODE. That was just a sample. > There are some other situations that need to change it. > I'll read more about RMODE(SPLIT). > thanks > >
Re: Reseting RMODE
On 12/2/2023 7:19 AM, Peter Relson wrote: In the RMODE=SPLIT case you can end up with one part of the executable in one RMODE and the other part in another RMODE and V-Con's between the two parts are resolved at module fetch time. Which is BTW ultra-cool functionality! (Too bad they don't allow tri-modal splitting... ) We have a product that uses RMODE(SPLIT) for 64-bit and 31-bit CSECTs. It does this because many z/OS services still require AMODE(31). The RMODE(64) code BASSMs to the RMODE(31) CSECT to call those services. Module fetch splits them for us at load time. It's a beautiful thing... For the occasional AMODE(24) requirement (extremely rare), we usually just copy a tiny bit of self-contained code to a dynamically-acquired 24-bit work area somewhere and BASSM to it. If it's an RMODE(24) exit point or something, that code loads some previously-saved registers from the 24-bit work area and BASSMs to a routine above the line or above the bar to do whatever. These 24-bit work areas tend to be *very* small -- usually less than 256 bytes in length (but we round to a cache line boundary). -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: comment continuation macro invocation
I just thought it was odd that the continued comments column is different for an instruction vs a macro. Perhaps the difference is that the data in column 16 of the continuation line of the macro invocation is actually part of the macro invocation, not a comment. Consider: MACRO M =2,=3 LHI , MEND With M A=1, this is <* in col 72> B=1 a comment Which is the same as M A=1,B=1 M A=1 this is a comment which gets ASMA432W Continuation statement may be in error - comma omitted from continued statement. and M A=1 this is a comment which is fine. The definition appears to let the assembler help with a common trivial error (at the cost of minor annoyance if you really wanted a comment), While letting you provide a nicely commented macro invocation (perhaps putting a comment on each line with keyword=value) such as M A=1,Set the A parameter to ...<* in col 72> B=2,Set the B parameter to ...<* in col 72> ... Peter Relson z/OS Core Technology Design
Reseting RMODE
It sounds like the OP might not fully understand RMODE. RMODE is a directive to the binder and loader of where in storage to place a module. As was mentioned, the granularity is on a section basis, and the directive is applied at module fetch time when store is acquired into which to place the module. The module is where the module is. If you need to be in AMODE 24 "at some point" then that part of the module must be RMODE 24. The RMODE of a load module or program object is generally the minimum of the RMODEs of the sections that comprise that executable. An exception is, as Ed Jaffe mentioned, when something like RMODE=SPLIT is used on the bind of a program object. In the RMODE=SPLIT case you can end up with one part of the executable in one RMODE and the other part in another RMODE and V-Con's between the two parts are resolved at module fetch time. Peter Relson z/OS Core Technology Design
Re: RES: Reseting RMODE
This conversation is making less and less sense. Since when does TPUT use a DCB? On the original question: RMODE sets a flag on the module that ultimately tells program fetch to load your program above or below the line (or bar, these days). Once loaded, what do you expect to happen on an RMODE change? You want program fetch to somehow delete the above the line copy and reload it below? Sorry, but that's ridiculous. If you think your code needs to be RMODE 24 for any reason, then it must be always. sas On Sat, Dec 2, 2023 at 5:48 AM João Reginato wrote: > I use TPUT sometimes as a trace tool only and it uses a DCB that must be > below the line. > As I just use it in debugging situations, and inside a macro, that was > easiest to me do this way. > But the discussion is not the TPUT but RMODE. That was just a sample. > There are some other situations that need to change it. > I'll read more about RMODE(SPLIT). > thanks > >
RES: Reseting RMODE
Ok but it could be changed. Why not? -Mensagem original- De: IBM Mainframe Assembler List Em nome de Ed Jaffe Enviada em: sexta-feira, 1 de dezembro de 2023 17:01 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE On 12/1/2023 11:27 AM, Jon Perryman wrote: > On Fri, 1 Dec 2023 11:06:16 -0300, João Reginato > wrote: > >> How can I reset RMODE without receive >> ASMA186E AMODE/RMODE already set for this ESD item Once set, such attributes cannot be changed. It makes no sense to change them. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
RES: Reseting RMODE
So why there is an RMODE instruction in HLASM? If I use a DCB inside my pgm it must be defined in RMODE 24, right? So how can I tell it to the binder at compilation time? -Mensagem original- De: IBM Mainframe Assembler List Em nome de Tony Harminc Enviada em: sexta-feira, 1 de dezembro de 2023 19:42 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE On Fri, 1 Dec 2023 at 16:07, João Reginato wrote: > Depending on the situation, yes, it does make sense during a compilation > phase > I don't think it does. Could you give a code example? Are you possibly confusing RMODE/AMODE assembler instructions with the SAMxx machine instructions? Tony H. -Mensagem original- > De: IBM Mainframe Assembler List Em > nome de Ed Jaffe > Enviada em: sexta-feira, 1 de dezembro de 2023 17:01 > Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Assunto: Re: Reseting RMODE > > On 12/1/2023 11:27 AM, Jon Perryman wrote: > > On Fri, 1 Dec 2023 11:06:16 -0300, João Reginato > wrote: > > > >> How can I reset RMODE without receive > >> ASMA186E AMODE/RMODE already set for this ESD item > > Once set, such attributes cannot be changed. It makes no sense to change > them. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system > into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. >
RES: RES: Reseting RMODE
I use TPUT sometimes as a trace tool only and it uses a DCB that must be below the line. As I just use it in debugging situations, and inside a macro, that was easiest to me do this way. But the discussion is not the TPUT but RMODE. That was just a sample. There are some other situations that need to change it. I'll read more about RMODE(SPLIT). thanks -Mensagem original- De: IBM Mainframe Assembler List Em nome de Ed Jaffe Enviada em: sexta-feira, 1 de dezembro de 2023 19:57 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: RES: Reseting RMODE On 12/1/2023 1:06 PM, João Reginato wrote: > But I have a program that can or not call TPUT. > If it calls, so I'd like to set RMODE 24, otherwise 31. We issue TPUT all over the place in 31-bit mode (AMODE/RMODE). If I did have a function that required RMODE(24), I would not force an entire module below the line just for that. I would use a different technique, for example splitting the RMODE(24) code into its own CSECT and linking with RMODE(SPLIT). -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: comment continuation macro invocation
A machine instruction can only be continued by coding the operands to the end of the line and using a continuation indicator, so once a space or comment on the same line has been encountered, anything starting in column 16 on the next line could only be a comment and there is no ambiguity. Some statements such as macro instructions use the alternative statement format, where an operand can be followed by a comma and continued in column 16 on the next line, and the operands may be followed by comments on each line. In this case, if there is no comma following the operands but there is text in column 16 on the next line, this might indicate incorrect continuation, so the FLAG(CONT) warning is issued. See the Language Reference topic "Continuation Lines" for full details. Jonathan Scott, HLASM IBM Hursley, UK
