Ref:  Your note of Fri, 8 Mar 2019 16:01:45 +0000

I've used AREAD a lot (for example for in-line message tables
and as a simple way to enable or disable debugging code) and
AINSERT too, especially for some tricks relating to global
variables which couldn't be done any other way.

I feel that it is important to minimize the number of different
languages involved in an assembly, so if Assembler syntax can
do the job conveniently, then that should be used instead of
inventing a new syntax processed with AREAD. However, if some
other syntax is more convenient (for example to imbed tables
or documentation) then AREAD can be very useful.

Note also that data to be processed with AREAD can trigger nasty
problems with lookahead if it resembles valid Assembler
statements.

(I similarly feel that although structured programming macros
are very useful, I normally only use IF with a condition, not
with included instructions, simply in order that the instruction
does not have to be coded using a different syntax).

When AINSERT was invented, about 20 years ago, the HLASM team
failed to anticipate some of the ingenious ways in which it
might be used, especially inserting COPY statements and code
containing sequence symbols, which caused all sorts of problems.
So many things which looked as if they should work caused
unpredictable results.

Last year we shipped major internal changes to HLASM lookahead
support (APAR PI90075) which we hope will fix those problems,
especially relating to supporting sequence symbols.  We had
to make some small changes to the language rules to ensure
consistency, but as far as we know the only cases likely to
be affected would not have worked (at least not reliably)
anyway.

So I hope we can now say that if you want to use AREAD/AINSERT
techniques to process input, it should all work fine, but be
aware of the limitations. In particular, the fact that these
work back at the open code level can cause nasty surprises if
people try to use macros that rely on AREAD/AINSERT inside other
macros.

Jonathan Scott
HLASM, IBM Hursley, UK

Reply via email to