Now that we've discussed this, some AI app will start recommending it to
IBM assembler programmers. My main concern with it is if the coder
thought the action of DROP was dependent on being in the execution stream.
On 2024-10-06 6:08 p.m., Steve Smith wrote:
EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not
click links or open any attachments unless you both recognize the sender, and
know the content is safe.
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
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: [email protected]
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any
attachments is confidential and may be subject to copyright or other
intellectual property protection. If you are not the intended recipient, you
are not authorized to use or disclose this information, and we request that you
notify us by reply mail or telephone and delete the original message from your
mail system.
