"IBM Mainframe Assembler List" <ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on 
08/16/2023 08:24:37 AM:
> I'd think that many would find it strange to have the equates 
> precede the field definition.
> If you must use "*" for the equate, that is appropriate.
> 
> Or, you might choose an approach such as the following:
> F1       DS    B
> F1B0     EQU   F1,X'80'


        I can see that point.  Some might also be uncomfortable having an 
unnamed data field as well.  Thus, naming the field and using it as a 
reference point in the following equated bit masks is a good idea.


"IBM Mainframe Assembler List" <ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on 
08/16/2023 08:40:56 AM:
> With regard to someone calling the macros with a symbol that was not
> defined with them in mind, an additional hack is possible; use the 
> type operand of the EQU to designate 8-bit, 16-bit HH, 16-bit HL, 
> 16-bit LH or 16-bit LL, and test it in the macros.


        I can see the value of being able to do some validation in the 
macro.  However, in an effort to "help" the programmer not shoot 
themselves in the foot, there have been cases where it limits the 
flexibility of the programmer to express their individuality in how they 
want to code things.  For example, if I limit the macro to validate for 
binary masks and the programmer wants to use hexadecimal masks, they might 
not be too happy.  So, if I allow either binary masks OR hexadecimal masks 
and the programmer wants to use character or numeric masks then, again, 
they might feel restricted.  Where do you draw the line?


Sincerely,

Dave Clark
-- 
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331





*********************************************************************************************
This email message and any attachments is for use only by the named 
addressee(s) and may contain confidential, privileged and/or proprietary 
information. If you have received this message in error, please 
immediately notify the sender and delete and destroy the message and all 
copies. All unauthorized direct or indirect use or disclosure of this 
message is strictly prohibited. No right to confidentiality or privilege 
is waived or lost by any error in transmission. 
*********************************************************************************************

Reply via email to