Oppolzer - Informatik / Blog

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

ASSEMBLER-L - Umbau zentraler Makros auf relative Sprünge (baseless)


Re: Relative Branches / IBM macros


Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>




2013.04.06 16:15:15

Thank you all for your valuable suggestions.

I would just like to keep you informed: adding SYSSTATE ARCHLVL=2 to the central
startup macro fixed all the issues I had with the IBM macros, for example

the other issues were in our own macros, and I fixed them or I'll fix them step
by step.

What I did in the last few hours: I added to some of our SP macros and to the
procedure macros some logic, which allows them to produce trace output, if a
global trace switch is on (GBLB &AVGBTRC). That is, if you have doubt about the
logic flow, you compile your module with this switch on. Works without problems.
With code registers, this could not have been done, because the code areas would
grow too large, but with code register less coding, this is no problem at all.

I have the problem that there are some very old programs where I have some
problems to understand what they are doing in certain cases, but now, as I
migrated them to code register less coding, I can examine the logic without

Thank you again, and have a nice weekend.

Regards, Bernd

Am 06.04.2013 15:45, schrieb P.R.:
> To summarize:
> We are talking about code-register-less programming, not
> base-register-less programming.
> There is still expectation that there be a base register to access static
> data (such as literals)
> - Specify SYSSTATE ARCHLVL=x to match what you "know". For supported
> releases (back to z/OS 1.6) use 2.
> - Specify SYSSTATE OSREL=x to match what you know about your minimum
> release (this won't help the specific problem, but is good style).
> - Use IEABRC(X)
> That covers a large percentage of IBM-provided macros.
> Change to execute form when needed or establish temporary code
> addressability around macros that have problems.
> Let us know of macros for which only the "temporary code addressability"
> approach works. Maybe they'll get improved some day if we're told of them;
> we are not trying to find such cases on our own.  But for example, we
> would not change R-form GETMAIN because there are far better options
> available that work find (such as RC- or RU- form GETMAIN).
> P.R.
> z/OS Core Technology Design

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie