----- Original Message -----
From: "Paul Gilmartin" <[email protected]>
To: <[email protected]>
Sent: Wednesday, June 03, 2020 3:26 AM
Subject: Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:58:00, David Woolbright wrote:
I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one
large credit card processing company for many years and their standard was to use EQU * as the
target of all branches, mainly so new lines could be added easily. I’ve never had an odd address
created accidentally using this technique, but it’s also the case that the assembler will warn you
in cases where you do have an unfavorable address. I’m in the process of revising many years of
teaching material into book format, so your opinions on this matter to me. Using EQU for targets
would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m
wrong.
LABEL DS 0H Guarantees alignment with no drawback.
LABEL EQU * Risks misalignment to save one keystroke in source.
I was once involved with a project tnat had (like):
B ENDEYECATCHER
DC C'Whatever' Eyecatcher
... more data areas ...
ENDEYECATCHER EQU *
The eyecatcher grew to an odd number of bytes (Y2K-type problem)
and code broke. Because of macro nesting, the remedy was:
B ENDEYECATCHER
DC C'Whatever' Eyecatcher
DS 0H
... more data areas ...
ENDEYECATCHER EQU *
STM R14,R13,
=======================
B ENDEYECATCHER
DC C'Whatever' Eyecatcher
DS 0H
... more data areas ...
DS 0H <<<<============== REQUIRED HERE, NOT AS
ABOVE
ENDEYECATCHER EQU *
STM R14,R13,
=======================
I pointed out that this introduced a needless slack byte
half the time. My suggestion was overruled because of
code ownership.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
