RES: Reseting RMODE
I meant "receive the error msg that follows": ASMA186E AMODE/RMODE already set for this ESD item I know what RMODE does do. But I have a program that can or not call TPUT. If it calls, so I'd like to set RMODE 24, otherwise 31. But 31 was already set in the beginning of the CSECT. It could simply cancel the previous RMODE and set the new one. Just a suggestion. Have a nice weekend -Mensagem original- De: IBM Mainframe Assembler List Em nome de Jon Perryman Enviada em: sexta-feira, 1 de dezembro de 2023 16:27 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE 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 What do you mean by "receive"? RMODE is not a machine instruction (e.g. MVC). Instead, the linkage editor verifies where you want this CSECT to reside in storage. Only 1 RMODE is allowed per CSECT because the CSECT cannot be moved once it is in storage. Are you thinking that RMODE must be changed? Set the RMODE to the highest RMODE that your code supports and the linkage editor / loader will handle it correctly. For instance, you code RMODE 31, then it can be linked into a load module that is either RMODE 31 or RMODE 24 without any program changes.
RES: Reseting RMODE
Depending on the situation, yes, it does make sense during a compilation phase -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: 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
As I've said before, I wasn't clear enough here. My intent is to change the RMODE during the compilation phase only. I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I cannot change it because the HLASM doesn't allow that. despite it hasn't finished the compilation of all my csects, issuing the message reported before. João -Mensagem original- De: IBM Mainframe Assembler List Em nome de Peter Relson Enviada em: domingo, 3 de dezembro de 2023 14:39 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE The starting point regarding using a DCB (that does need to be below 16M) is that use of non-reentrant code is discouraged (if for potential performance issues if nothing else, if you have not well-separated the instruction and static data from dynamic data). Any reentrant module will naturally be getmaining its dynamic storage and may choose to have that storage be LOC=24 if that is what it needs. Or the DCB can be acquired separately, while having the module be RMODE 31. RMODE for a module, as have been stated very clearly by multiple folks, cannot be "switched" mid-stream because that is not how the module was loaded into storage. You can have multiple CSECTs in a load module or program object, but unless it is a program object with RMODE=SPLIT the overall RMODE will generally be the least common denominator (i.e., RMODE 24 if there is an RMODE 24 CSECT even if everything else is RMODE 31). As to why we do not support tri-modal RMODE=SPLIT: $$ and performance and avoiding undesired increase of common storage. I've lost track of what z/OS-oriented cases require AMODE 24 (and provide no way to get appropriate functionality if AMODE 31). RMODE 24 for data such as a DCB, affects only non-reentrant modules. So try to avoid that. Peter Relson z/OS Core Technology Design
RES: Reseting RMODE
Yes that solves it. Thank you -Mensagem original- De: IBM Mainframe Assembler List Em nome de Paul Gilmartin Enviada em: segunda-feira, 4 de dezembro de 2023 12:48 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE (Don't be greedy; don't set personal "Reply-to:") On 12/4/23 07:28:51, João Reginato wrote: > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. >. Ir would be marginally useful if HLASM, when the programmer codes conflicting RMODE instructions, chose the one most restrictive. But you can simulate this by setting a GBLA wherever any RMODE is needed and choosing the least one with AIF logic near the end of your assembly. -- gil
RES: Reseting RMODE
Yes, that's it -Mensagem original- De: IBM Mainframe Assembler List Em nome de Gary Weinhold Enviada em: segunda-feira, 4 de dezembro de 2023 13:59 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE I think I understand: you wish the last RMODE in a CSECT to override all previous RMODEs in the CSECT or possibly, as Shmuel suggests, the most restrictive to override all others. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: December 4, 2023 11:44 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Reseting RMODE is there an RFE for an RMODE(MIN) option to accept multiple RMODE statements and use the most restrictive? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, December 4, 2023 10:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Reseting RMODE (Don't be greedy; don't set personal "Reply-to:") On 12/4/23 07:28:51, João Reginato wrote: > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. >. Ir would be marginally useful if HLASM, when the programmer codes conflicting RMODE instructions, chose the one most restrictive. But you can simulate this by setting a GBLA wherever any RMODE is needed and choosing the least one with AIF logic near the end of your assembly. -- gil
RES: Reseting RMODE
That's it Thank you all -Mensagem original- De: IBM Mainframe Assembler List Em nome de Gary Weinhold Enviada em: segunda-feira, 4 de dezembro de 2023 13:59 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Reseting RMODE I think I understand: you wish the last RMODE in a CSECT to override all previous RMODEs in the CSECT or possibly, as Shmuel suggests, the most restrictive to override all others. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: December 4, 2023 11:44 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Reseting RMODE is there an RFE for an RMODE(MIN) option to accept multiple RMODE statements and use the most restrictive? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, December 4, 2023 10:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Reseting RMODE (Don't be greedy; don't set personal "Reply-to:") On 12/4/23 07:28:51, João Reginato wrote: > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. >. Ir would be marginally useful if HLASM, when the programmer codes conflicting RMODE instructions, chose the one most restrictive. But you can simulate this by setting a GBLA wherever any RMODE is needed and choosing the least one with AIF logic near the end of your assembly. -- gil
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.
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: 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: 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: 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.
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
João, What has been hinted at here is that all you need to do is to have two CSECTs, one which is RMODE(ANY) and a second one which is RMODE(24). You can have as many CSECTs in a single assembly as you wish. Then, just call the RMODE(24) CSECT when you need it. Tom Harper Phoenix Software International Sent from my iPhone > On Dec 4, 2023, at 9:29 AM, João Reginato wrote: > > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. > > João > > -Mensagem original- > De: IBM Mainframe Assembler List Em nome > de Peter Relson > Enviada em: domingo, 3 de dezembro de 2023 14:39 > Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Assunto: Re: Reseting RMODE > > The starting point regarding using a DCB (that does need to be below 16M) is > that use of non-reentrant code is discouraged (if for potential performance > issues if nothing else, if you have not well-separated the instruction and > static data from dynamic data). > > Any reentrant module will naturally be getmaining its dynamic storage and > may choose to have that storage be LOC=24 if that is what it needs. Or the > DCB can be acquired separately, while having the module be RMODE 31. > > RMODE for a module, as have been stated very clearly by multiple folks, > cannot be "switched" mid-stream because that is not how the module was > loaded into storage. > > You can have multiple CSECTs in a load module or program object, but unless > it is a program object with RMODE=SPLIT the overall RMODE will generally be > the least common denominator (i.e., RMODE 24 if there is an RMODE 24 CSECT > even if everything else is RMODE 31). > > As to why we do not support tri-modal RMODE=SPLIT: $$ and performance and > avoiding undesired increase of common storage. > I've lost track of what z/OS-oriented cases require AMODE 24 (and provide no > way to get appropriate functionality if AMODE 31). > RMODE 24 for data such as a DCB, affects only non-reentrant modules. So try > to avoid that. > > Peter Relson > z/OS Core Technology Design 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
Yes, I know that but it doesn't solve my problem -Mensagem original- De: Tom Harper Enviada em: segunda-feira, 4 de dezembro de 2023 11:49 Para: jb.regin...@gmail.com Cc: ASSEMBLER-LIST@listserv.uga.edu Assunto: Re: RES: Reseting RMODE João, What has been hinted at here is that all you need to do is to have two CSECTs, one which is RMODE(ANY) and a second one which is RMODE(24). You can have as many CSECTs in a single assembly as you wish. Then, just call the RMODE(24) CSECT when you need it. Tom Harper Phoenix Software International Sent from my iPhone > On Dec 4, 2023, at 9:29 AM, João Reginato wrote: > > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. > > João > > -Mensagem original- > De: IBM Mainframe Assembler List Em nome > de Peter Relson > Enviada em: domingo, 3 de dezembro de 2023 14:39 > Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Assunto: Re: Reseting RMODE > > The starting point regarding using a DCB (that does need to be below 16M) is > that use of non-reentrant code is discouraged (if for potential performance > issues if nothing else, if you have not well-separated the instruction and > static data from dynamic data). > > Any reentrant module will naturally be getmaining its dynamic storage and > may choose to have that storage be LOC=24 if that is what it needs. Or the > DCB can be acquired separately, while having the module be RMODE 31. > > RMODE for a module, as have been stated very clearly by multiple folks, > cannot be "switched" mid-stream because that is not how the module was > loaded into storage. > > You can have multiple CSECTs in a load module or program object, but unless > it is a program object with RMODE=SPLIT the overall RMODE will generally be > the least common denominator (i.e., RMODE 24 if there is an RMODE 24 CSECT > even if everything else is RMODE 31). > > As to why we do not support tri-modal RMODE=SPLIT: $$ and performance and > avoiding undesired increase of common storage. > I've lost track of what z/OS-oriented cases require AMODE 24 (and provide no > way to get appropriate functionality if AMODE 31). > RMODE 24 for data such as a DCB, affects only non-reentrant modules. So try > to avoid that. > > Peter Relson > z/OS Core Technology Design 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: RES: RES: Reseting RMODE
I think it does solve your problem. What doesn’t it solve? Sent from my iPhone > On Dec 4, 2023, at 10:01 AM, João Reginato wrote: > > Yes, I know that but it doesn't solve my problem > > -Mensagem original- > De: Tom Harper > Enviada em: segunda-feira, 4 de dezembro de 2023 11:49 > Para: jb.regin...@gmail.com > Cc: ASSEMBLER-LIST@listserv.uga.edu > Assunto: Re: RES: Reseting RMODE > > João, > > What has been hinted at here is that all you need to do is to have two > CSECTs, one which is RMODE(ANY) and a second one which is RMODE(24). > > You can have as many CSECTs in a single assembly as you wish. > > Then, just call the RMODE(24) CSECT when you need it. > > Tom Harper > Phoenix Software International > > Sent from my iPhone > >> On Dec 4, 2023, at 9:29 AM, João Reginato wrote: >> >> As I've said before, I wasn't clear enough here. >> My intent is to change the RMODE during the compilation phase only. >> I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I >> cannot change it because the HLASM doesn't allow that. despite it hasn't >> finished the compilation of all my csects, issuing the message reported >> before. >> >> João >> >> -Mensagem original- >> De: IBM Mainframe Assembler List Em nome >> de Peter Relson >> Enviada em: domingo, 3 de dezembro de 2023 14:39 >> Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Assunto: Re: Reseting RMODE >> >> The starting point regarding using a DCB (that does need to be below 16M) is >> that use of non-reentrant code is discouraged (if for potential performance >> issues if nothing else, if you have not well-separated the instruction and >> static data from dynamic data). >> >> Any reentrant module will naturally be getmaining its dynamic storage and >> may choose to have that storage be LOC=24 if that is what it needs. Or the >> DCB can be acquired separately, while having the module be RMODE 31. >> >> RMODE for a module, as have been stated very clearly by multiple folks, >> cannot be "switched" mid-stream because that is not how the module was >> loaded into storage. >> >> You can have multiple CSECTs in a load module or program object, but unless >> it is a program object with RMODE=SPLIT the overall RMODE will generally be >> the least common denominator (i.e., RMODE 24 if there is an RMODE 24 CSECT >> even if everything else is RMODE 31). >> >> As to why we do not support tri-modal RMODE=SPLIT: $$ and performance and >> avoiding undesired increase of common storage. >> I've lost track of what z/OS-oriented cases require AMODE 24 (and provide no >> way to get appropriate functionality if AMODE 31). >> RMODE 24 for data such as a DCB, affects only non-reentrant modules. So try >> to avoid that. >> >> Peter Relson >> z/OS Core Technology Design > > > > 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. > 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
ENC: RES: RES: Reseting RMODE
I want just ONE CSECT be allowed to change the RMODE at compilation time, accepting 2 or more RMODE as my needs. Like this (the simplest example): C1 CSECT C1 RMODE 31 SAVE (14,12) RETURN (14,12) AIF (D'DCB).FIN DCB DCB DDNAME=DCB C1 RMODE 24 .FINEND GOT IT? -Mensagem original- De: Tom Harper Enviada em: segunda-feira, 4 de dezembro de 2023 12:12 Para: jb.regin...@gmail.com Cc: ASSEMBLER-LIST@listserv.uga.edu Assunto: Re: RES: RES: Reseting RMODE I think it does solve your problem. What doesn’t it solve? Sent from my iPhone > On Dec 4, 2023, at 10:01 AM, João Reginato wrote: > > Yes, I know that but it doesn't solve my problem > > -Mensagem original- > De: Tom Harper > Enviada em: segunda-feira, 4 de dezembro de 2023 11:49 > Para: jb.regin...@gmail.com > Cc: ASSEMBLER-LIST@listserv.uga.edu > Assunto: Re: RES: Reseting RMODE > > João, > > What has been hinted at here is that all you need to do is to have two > CSECTs, one which is RMODE(ANY) and a second one which is RMODE(24). > > You can have as many CSECTs in a single assembly as you wish. > > Then, just call the RMODE(24) CSECT when you need it. > > Tom Harper > Phoenix Software International > > Sent from my iPhone > >> On Dec 4, 2023, at 9:29 AM, João Reginato wrote: >> >> As I've said before, I wasn't clear enough here. >> My intent is to change the RMODE during the compilation phase only. >> I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I >> cannot change it because the HLASM doesn't allow that. despite it hasn't >> finished the compilation of all my csects, issuing the message reported >> before. >> >> João >> >> -Mensagem original- >> De: IBM Mainframe Assembler List Em nome >> de Peter Relson >> Enviada em: domingo, 3 de dezembro de 2023 14:39 >> Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Assunto: Re: Reseting RMODE >> >> The starting point regarding using a DCB (that does need to be below 16M) is >> that use of non-reentrant code is discouraged (if for potential performance >> issues if nothing else, if you have not well-separated the instruction and >> static data from dynamic data). >> >> Any reentrant module will naturally be getmaining its dynamic storage and >> may choose to have that storage be LOC=24 if that is what it needs. Or the >> DCB can be acquired separately, while having the module be RMODE 31. >> >> RMODE for a module, as have been stated very clearly by multiple folks, >> cannot be "switched" mid-stream because that is not how the module was >> loaded into storage. >> >> You can have multiple CSECTs in a load module or program object, but unless >> it is a program object with RMODE=SPLIT the overall RMODE will generally be >> the least common denominator (i.e., RMODE 24 if there is an RMODE 24 CSECT >> even if everything else is RMODE 31). >> >> As to why we do not support tri-modal RMODE=SPLIT: $$ and performance and >> avoiding undesired increase of common storage. >> I've lost track of what z/OS-oriented cases require AMODE 24 (and provide no >> way to get appropriate functionality if AMODE 31). >> RMODE 24 for data such as a DCB, affects only non-reentrant modules. So try >> to avoid that. >> >> Peter Relson >> z/OS Core Technology Design > > > > 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. > This e
