Hi Steve:
Well, I do recall using ____ EQU * in the old days (card decks
and all) and we started discussing this and most of us started
using ____ DS 0H to ensure we were on a correct boundary for an
instruction. Back in those days, the closer data was to the
instruction that used it, the faster the machine seemed to run.
Especially once we got into Virtual Storage machines as opposed
to REAL machines.
And I think I saw your post in IBM Main about this as well.
I'm not sure if that was in a NaSPA chapter meeting in Silicon
Valley, or if it was in the early 1990's when IBM Main became
available. And I seem to remember another group for contracting,
and discussing mainframe issues before NaSPA. All that stuff now
is just a hazy memory.
Regards,
Steve Thompson
On 10/6/2024 6:08 PM, Steve Smith wrote:
EQU * has exactly the same problem. Nevertheless, it's ridiculously
popular (by those who "know" it will always be on a halfword boundary, and
of course the many more who don't know much).
For this case of an ordinary symbol not being allowed on DROP, yet actually
implemented with only a warning, I say that's just wrong. The correct
behavior would be to not create the symbol, and issue an E-level message.
There's no benefit to accepting undocumented usage. Nevertheless, nothing
is perfect, even HLASM, and I'm not sure it's worth the effort to change
it. Your program may well be the only one in the world where someone tried
this.
sas
On Sun, Oct 6, 2024 at 4:30 PM Steve Thompson <[email protected]> wrote:
Hi:
What I was reporting is how it was coded in a program (in
production). Which was astonishing to me!! I'd never seen any one
attempt this before that I can remember.
We have discussed this also on/in IBM Main. It was pointed out by
someone else, that this could lead to a S0C6 -- which is what
bothered me about how HLASM dealt with this to start with.
In all the code I've written and/or worked on from the S/360-20
through z/16s, this was the first time I can recall someone
attempting to "branch" to a drop statement. Or any other
assembler directive.
Your example, if it was on an odd boundary would result in S0C6 -
Specification error (which someone demonstrated on/in IBM Main).
I certainly hope the HLASM folks will take another look at this
and realize how this could be even more confusing to newbie ALC
programmers who may do this and then have such a directive end up
being preceded with something like DS X that would put the next
byte on an odd byte boundary (the S0C6 problem).
Regards,
Steve Thompson
