Oppolzer - Informatik / Blog

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 J.P.:
> 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.
>
> J.P.
>
>
> ----- Original Message ----
>> From: S.F.
>> 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
>>
>> S.F.
>>> 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
>>> --
>>> T.M.