I have an old macro I wrote in the late 80ies that generates code to invoke WTO with variable text. Initially, the macro did not generate reentrant code. Then I changed that quite a while ago, but did not care to separate the instructions from the data it generates. The code merely jumped around the static data.
Although that code is never used in perfomance critical environments, I now want to separate instructions and data, just for the fun of it,to avoid cache trashing. First thought was to generate a separate, named CSECT (or RSECT) to assemble the data statements. Then I recognized that there would be a conflict if multiple sources were using the macro, and the objects would be linked together. Allowing the user to choose the CSECT name is only half an option. What if he does not now that another object was also using the macro and by chance the same CSECT name was used? CSECT names longer than 8 would force the use of GOFF (If I understand correctly), which I do not want to force. So building a longer name, most probably unique name does not work either. I never used unnamed CSECTs, but am thinking, this could be an option. Unnamed CSECTs cannot be resumed, so each invocation of the macro would generate a new unnamed section. A load address instruction with an =A(dataxyz), where dataxyz is a unique name in the unnamed section, would make the data addressable to the code. Would this work? Can there be a problem linking mulitple objects, each unsing the macro, into one load module? Any other problem? Any other solution? -- Peter Hunkeler
