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 > >
