I don't have a dog in this fight; I was just trying to clarify what the issue was. It seems reasonable, but I haven't come up with a use case.
If I were designing USING ab initio I would probably allow the base-displacement form only on a labelled USING, if at all. The only real way to determine the need is for someone to do an RFE with a good business case and see how many other customers concur. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jonathan Scott <[email protected]> Sent: Wednesday, February 28, 2024 7:42 AM To: [email protected] Subject: Re: Why am I getting ASMA145E (was Re: Macro parameters: parsing a There are certainly cases where a base-displacement operand on USING would appear at first glance to make sense, as in the suggested case: USING SOMELABEL,24(R3) or with a symbolic offset expression USING SOMELABEL,TWENTY_FOUR(R3) However, even in concept some of the implications are not obvious. This would obviously be expected to work like a dependent USING, but it does not have a base USING giving the list of registers to be used, so it is not the same. One might expect it to act as if there was an implicit base USING for R3 pointing 24 bytes earlier, but without a label, which would be a new concept. But does that mean one could issue a DROP R3 and that R3 would be currently considered in use as a base so that a new USING for R3 would drop this use? At least since the language enhancement for PH42188 in 2021 to allow DROP for a relocatable symbol, one would be able to use DROP SOMELABEL. These are examples of the sorts of issues that arise when we investigate possible language enhancements. If there is a strong justification for some enhancement, it may be worth working through such issues and finding solutions. However, as far as I can see, the current suggestion would appear to require new concepts and raise complications which appear to be out of proportion to the potential benefits. Jonathan Scott, HLASM IBM Hursley, UK
