I would like to thank you all for your suggestions and for this discussion.
The reason why I will stay with my current logic (the large startup macro
at the beginning, followed by the code, followed by the static definitions)
is that there are several thousand existant programs which are not yet
baseless
and which follow this convention, and I need them to compile without
modification.
The startup macro has got some new keyword parms which simply puts the
using points at another place (away from the module start, to the start
of the
static data area) and so it makes the code area baseless - nothing else
to do for the developers - if the code itself and the macros which are used
can tolerate this.
What I do to support this: IEABRCX DEFINE and SYSSTATE ARCHLVL=2
in the startup macro - iff the new keyword parms are set.
Now I hope that the remaining ca. 50 ASSEMBLER developers will use this ...
and will step by step change their modules by using the new keyword parm
(most of the developers are PL/1 developers, not ASSEMBLER).
Kind regards
Bernd
Am 12.04.2013 16:23, schrieb Jon Perryman:
Tom is not saying you should change your coding style. You leave the data areas
and literals at the end of your source code. You add LOCTR statements into your
program to change generated machine code sequence.
Jon Perryman
----- Original Message ----
From: Scott Ford <[email protected]>
This is a matter of style to me and experience level. I learned the data
areas and liberals at the tail end of your code ...always worked for me. Doesn't
mean that's the only way to to do II
Scott ford
Sure you can. How much of what is generated by that startup macro has to
be
before the data area location counter is defined?
And: the LTORG at the end of the program needs addressibility;
Of course. LOCTR takes care of that
--
Tom Marchant
