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
