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 <jb.regin...@gmail.com> wrote: > > Yes, I know that but it doesn't solve my problem > > -----Mensagem original----- > De: Tom Harper <tomhar...@phoenixsoftware.com> > 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 <jb.regin...@gmail.com> 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 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> 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 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.
