If you only have one copy of the area, you can use a simple dependent USING; if you have more, read up on labelled USING.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Bernd Oppolzer [[email protected]] Sent: Monday, April 5, 2021 6:17 PM To: [email protected] Subject: DSECT which refers to area inside CSECT Hello ASSEMBLER list, I have a problem which is difficult to explain, let me give it a try ... I am rewriting old ASSEMBLER modules which have SIIS problems. There are customer written macros which have inline parameter lists which are modified, which leads to SIIS performance problems. One elegant soluton is: the customer macros can generate reentrant code, if a global switch is set. If so, they put all their variable parts in a certain (global) DSECT called #DRENT, and a dynamic area for this DSECT is obtained by the startup macro. The nice thing about this is that the total size of this DSECT is computed automatically at the end by the ASSEMBLER and the startup macro can obtain the needed area size. (The #DRENT DSECT is addressed using register 13 with reentrant programs, and it simply is the area following the system save area, so there is no special register needed to address it in the reentrant case). I now decided to use this mechanism to get rid of the SIIS problems; I simply set the global switch to YES, although the programs are NORENT, and then define a "static #DRENT", much like this #DRENT_STATIC DS CL(#END_OF_DRENT-#DRENT) then I have to find a free register and identify the register with the "static #DRENT" by a USING instruction. (Register 13 is not possible in this case, because it is already occupied by the system save area in the startup macro, and this area cannot be extended). That is: I am cheating; the customer macros "think" they have to generate code for the reentrant case. This way, the SIIS problems disappear, because now the stores etc. have a distance big enough from the PSW position. It works, and in some processes, I have performance gains of 6 percent and more. And there is almost no change to the customer modules (only two new macro calls, and all SIIS problems in all macro calls throughout the whole module disappear). Now my problem: with several large programs, it is not easy to find a free register for the "static #DRENT". But: there are registers which access the static area of the program, that is, the area where the static definitions and the constants reside. say: register 10 is the base for those static definitions and constants. and: let's assume that the new "static #DRENT" can be positioned at the very beginning of this static and constant area How can I convince the ASSEMBLER to use register 10 during translation for both the #DRENT DSECT (inside the customer macros) and the static area (in the open code)? Is this possible? Is there a solution using new ASSEMBLER techniques like LOCTR etc.? I don't want to change the customer macros, because they are used in 1000s of other modules; only changes to the open code, if possible ... Thank you, kind regards Bernd
