Ref:  Your note of Fri, 1 Jan 2021 10:09:06 -0700

Paul Gilmartin wrote:
> > From: Jonathan Scott
> >
> > HLASM was therefore changed again by APAR PH05788 to tolerate
> > this incorrect usage, in that if CATTR with a given name was
> > first issued within a DSECT, the definition would be associated
> > with the most recently active CSECT.
>
> Two wrongs don't make a right.  Surely an APAR fix to Metal C
> could have been produced as promptly as tolerating breakage
> in HLASM.  "Toleration is the mother of mediocrity."

The way that CATTR should work is that the first occurrence with
a given class name defines a new GOFF element with that class
name within the current section.  The original bug was that
HLASM incorrectly defined it within the most recently defined
section, even if a previous section had been resumed.

However, the term "current section" caused some confusion, as
the earlier fix incorrectly used the current section in the
original assembler sense, which could be a DSECT, instead of
using it in the GOFF sense.  Code generated by Metal C could
result in defining the CATTR within a DSECT, causing a binder
error, or an assembler error if the same class name was already
associated with another section.  So HLASM needed to be fixed
again one way or another.

When GOFF is used, the current GOFF section for binder purposes
is determined by the current (or most recently active) START,
CSECT or RSECT.  A control section is then defined as an element
within that section with a class name of B_TEXT, and an external
entry point is defined at the start of that element with the
name specified on the section, so that for binding purposes it
is very similar to an object code control section.  CATTR can
then be used to define additional elements or parts within a
section.

Now that CATTR is correctly associated with the current section
in the GOFF sense, there is no problem with coding it within a
DSECT, as that does not affect the current GOFF section, so we
now count that as acceptable usage.

Some other HLASM bugs related to GOFF and CATTR were fixed at
the same time, for example to allow LOCTR to be used to resume
an existing CATTR element.

I guess it was also felt to be safer if Metal C explicitly
switched to the correct current section before issuing the
CATTR, which would work around the DSECT problem and would be
safer in the long term, so Metal C was fixed as well.

Jonathan Scott, HLASM
IBM Hursley, UK

Reply via email to