Self-documenting Bit Settings

[Dave Clark]

Given this:

FLAGS DC XL4'80000001'
LDAP_AUTH_ENABLED EQU X'00000001' LDAP AUTH IS ENABLED
USE_SSL EQU X'00000002' SSL IS ENABLED
STRICT_MODE EQU X'00000004' STRICT USER MAPPING
TRACE EQU X'80000000' ENABLE TRACING


It makes more sense to me (and is self-documenting) to code it
this way.

FLAGS DC A(LDAP_AUTH_ENABLED+TRACE)


But that yields aligned storage, correct? Is there a way to
achieve the same result but without aligned storage?

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

[Charles Mills]

AL4 ?

Charles

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
08/11/2023 01:43:18 PM:
> AL4 ?


I guess the question mark either means you weren't sure that would
result in no alignment or you weren't sure that is what I was asking for.
Well, I'd never thought of assigning a specific length to an address
constant. But, I tried it and it works as desired. Thanks.

[Seymour J Metz]

AL1(foo+bar...) is very common for flag bytes, and AL4 is conceptually the same paradigm.

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Dave Clark <dlc...@WINSUPPLYINC.COM>
Sent: Friday, August 11, 2023 2:19 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

[Jon Perryman]

> Dave Clark wrote:
> FLAGS DC A(LDAP_AUTH_ENABLED+TRACE)
> But that yields aligned storage, correct?

You'll need to test it but I believe AL4( ) ignores alignment.

[Charles Mills]

Sorry. Did not mean to be cryptic or obscure. By the question mark I meant
"why not?"

Why not AL4?

Yes, I never found it intuitive that A should be word-aligned and AL4 not,
but that is what it is.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark

Sent: Friday, August 11, 2023 11:19 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

[Kerry Liles]

I believe the presence of an explicit length in AL4 (for example) removes
the alignment constraints - irrespective of the length)

iCBW as often happens after 50+ years on various bits of hardware/software

[Paul Gilmartin]

On 8/11/23 16:42:06, Charles Mills wrote:
> Sorry. Did not mean to be cryptic or obscure. By the question mark I meant
> "why not?"
>
> Why not AL4?
>
> Yes, I never found it intuitive that A should be word-aligned and AL4 not,
> but that is what it is.

*But* AL0 *is* word-aligned. Go figger.

--
gil

[Seymour J Metz]

ITYM 0A

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Paul Gilmartin <00000014e0e4a59...@LISTSERV.UGA.EDU>
Sent: Friday, August 11, 2023 7:27 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

On 8/11/23 16:42:06, Charles Mills wrote:

[Charles Mills]

DS 0x (where by x I mean any constant type (A, F, H, D etc.), not a literal
X) I think always means (1) align for type x and then reserve no storage. DS
0F or DC 0A(123) both align to a fullword and then reserve no storage.

I am not familiar with AL0 and I am too lazy to look it up. By analogy to
AL4 it *should* do pretty much nothing at all.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]

[Steve Smith]

> I am not familiar with AL0 and I am too lazy to look it up. By analogy to
> AL4 it *should* do pretty much nothing at all.
>

It does something. But not what gil said.

>
> Charles
>
>

[Rene BRANDT]

Hi,

If you want it unaligned code it as :
FLAGS DC XL4(LDAP_AUTH_ENABLED+TRACE)

René

[Seymour J Metz]

Unless something has changed you can't use quoted symbols as the value of an X-type constant, although you can use SET symbols . So

FLAGS DC AL4(LDAP_AUTH_ENABLED+TRACE)

A technique that I have seen used in macros is to repurpose the length attribute in order to define both an address and a mask for each flag bit:

FLAGS DS 0AL4
FLAG1 DC AL1(L'TRACE)
TRACE EQU FLAG1,X'80' ENABLE TRACING
FLAG2 DC AL1(0)
FLAG3 DC AL1(0)
FLAG4 DC AL1(l'LDAP_AUTH_ENABLED+TRACE)
LDAP_AUTH_ENABLED EQU FLAG1,X'01' LDAP AUTH IS ENABLED
USE_SSL EQU FLAG4,X'02' SSL IS ENABLED
STRICT_MODE EQU FLAG4,X'04' STRICT USER MAPPING



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Rene BRANDT [000014a2846c666...@LISTSERV.UGA.EDU]
Sent: Sunday, August 13, 2023 2:23 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

[Jon Perryman]

> On Sunday, August 13, 2023 at 03:53:19 AM PDT, Seymour J Metz <sme...@gmu.edu> wrote:
> A technique that I have seen used in macros is to repurpose the length attribute in order to define 

> FLAG4              DC    AL1(l'LDAP_AUTH_ENABLED+TRACE)

The +TRACE in flag4 needs to be removed.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
08/13/2023 02:23:04 AM:

> If you want it unaligned code it as :
> FLAGS DC XL4(LDAP_AUTH_ENABLED+TRACE)

Would have been intuitive but, no. Neither the X nor the C types
allow parentheses for the value and, therefore, no arithmetic.

10 TEST DC XL4(LDAP_AUTH_ENABLED)
** ASMA035S Invalid delimiter - (LDAP_AUTH_ENABLED)
** ASMA435I Record 10 in SYSIPT on volume:

[Jon Perryman]

> On Sunday, August 13, 2023 at 03:53:19 AM PDT, Seymour J Metz <sme...@gmu.edu> wrote:
> A technique that I have seen used in macros is to repurpose the length attribute in order to define

> FLAG1 DC AL1(L'TRACE)
> TRACE EQU FLAG1,X'80' ENABLE TRACING

I strongly discourage the use length as a flag because it's inconsistent, confusing and serves no useful purpose. Be consistent with all other flag usage and if you want to document the flag field name, then include it in the comments. Anyone seeing this would ask themselves is there a bug for FLAG1. Code the following instead to include the flag field name:

TRACE EQU X'80' FLAG1 - ENABLE TRACING

[Jonathan Scott]

Although it may initially seem confusing, the technique of
defining a flag bit using EQU in the following form, using the
length attribute to provide the bit mask, provides a safe way to
ensure that the named flag is mapped to the correct field:

flag EQU field,mask

or (avoiding an unnecessary cross-reference to the field and
even a name for the field itself):

flag1 EQU *,mask1
flag2 EQU *,mask2
...
DS BL1 Flag byte

So for example, HLASM itself has some internal macros TF, SF and
CF (test flag, set flag and clear flag) which generate code such
as the following:

TF flag
+ TM flag,L'flag

I have seen many errors caused by code testing flags mask bits
in the wrong field after data areas have been modified, but this
technique eliminates that class of errors.

This is of course not the normal intended use of the length
attribute, but it means that independent flags and bit masks can
be set and tested as simply as in high level languages.

Jonathan Scott, HLASM
IBM Hursley, UK

[Jon Perryman]

> On Tuesday, August 15, 2023 at 02:29:07 AM PDT, Jonathan Scott <jonatha...@vnet.ibm.com> wrote:
> Although it may initially seem confusing, it provides a safe way to

> ensure that the named flag is mapped to the correct field:

>           TF  flag

> +        TM  flag,L'flag

The problem is inconsistency and not confusion nor safe. TCBCSTEP is a valid flag but if you Inadvertently code TF TCBCSTEP, it compiles successfully but clearly does not meet the obvious intent. You're exchanging 1 problem for another. 

> I have seen many errors caused by code testing flags mask bits

> but this technique eliminates that class of errors.

This technique doesn't fully eliminate this class of errors. If you diligently train / enforce all new employees on it's implementation and you never use flag bytes outside of your control, then you might consider it consistent.

I too have seen many errors concerning flag bytes. I easily solved this problem years ago which I'm surprised has not been included in the HLAsm toolkit. Using OPSYN for DC, DS and EQU, the flag and field name are collected in an array. By using that array, TF can be used consistently for all flag bytes.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/15/2023 04:53:03 AM:

> So for example, HLASM itself has some internal macros TF, SF and
> CF (test flag, set flag and clear flag) which generate code such
> as the following:
>
> TF flag
> + TM flag,L'flag

Ratz! Those macros are not on my system. ;-b

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/15/2023 02:07:32 PM:

> Ratz! Those macros are not on my system. ;-b

So, I whipped up my own simple versions and created a little test
program to see how it all works. It is even compatible with my macros for
conditional constructs. Thanks for the idea, Jonathan.

MACRO
&LABEL TF &F
&LABEL TM &F,L'&F TEST FLAG BYTE
MEND
MACRO
&LABEL SF &F
&LABEL OI &F,L'&F SET FLAG BYTE
MEND
MACRO
&LABEL CF &F
&LABEL NI &F,X'FF'-L'&F CLEAR FLAG BYTE
MEND

PRINT OFF
COPY IF IF/AND/ELSE/ENDIF CONSTRUCT
COPY SELECT SELECT/WHEN/ENDSL CONSTRUCT
COPY WHILE WHILE/WEXIT/WLOOP/WEND CONSTRUCT
PRINT ON

TEST CSECT 0
USING *,12
SAVE (14,12)
LR 12,15
SF FLAG3
IF FLAG3,(ON,TF),$NOOP
WTO 'FLAG3 IS ON'
ELSE
WTO 'FLAG3 IS OFF'
ENDIF
CF FLAG3
IF FLAG3,(ON,TF),$NOOP
WTO 'FLAG3 IS ON'
ELSE
WTO 'FLAG3 IS OFF'
ENDIF
RETURN (14,12),RC=0

DS 0D
FLAG1 EQU *,B'00000001'
FLAG2 EQU *,B'00000010'
FLAG3 EQU *,B'00000100'
FLAG4 EQU *,B'00001000'
FLAG5 EQU *,B'00010000'
FLAG6 EQU *,B'00100000'
FLAG7 EQU *,B'01000000'
FLAG8 EQU *,B'10000000'
DS BL1 FLAG BYTE
END TEST

[Abe Kornelis]

All,

The technique has been described extensively by
the late Dr. John Ehrman. I think it was a Share presentation.

I used to create my own version.
Works like a charm.
I love to be able to simply manage a bit by name,
not needing to care about the label used
to define the storage location.

Kind regards & happy programming!
Abe
===


Op 15/08/2023 om 20:54 schreef Dave Clark:

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/15/2023 03:09:13 PM:

> The technique has been described extensively by
> the late Dr. John Ehrman. I think it was a Share presentation.

Thanks for that. I put these comments in all three macros.

MACRO
&LABEL TF &FLAG TEST FLAG BIT(s)
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
.* This is a simple macro to make it easier to accurately manipulate *
.* a bit flag definition just by the equated bit mask name -- i.e., *
.* without having to know the name of the actual flag byte or the *
.* flag byte even having a name at all. *
.* *
.* As presented by the late Dr. John Ehrman of IBM at SHARE. *
.* *
.* The idea is, you can have a definition similar to the following. *
.* The actual flag byte does not need a name but you can specify one *
.* if you want it to show up in the cross-reference. The equated *
.* bit masks take on the location of the flag byte and the length of *
.* the equated bit mask is set to the bit mask, itself. *
.* *
.* FLAG1 EQU *,B'00000001' *
.* FLAG2 EQU *,B'00000010' *
.* FLAG3 EQU *,B'00000100' *
.* FLAG4 EQU *,B'00001000' *
.* FLAG5 EQU *,B'00010000' *
.* FLAG6 EQU *,B'00100000' *
.* FLAG7 EQU *,B'01000000' *
.* FLAG8 EQU *,B'10000000' *
.* DS BL1 FLAG BYTE *
.* *
.* NOTE: See also the SF macro and the CF macro. *
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
&LABEL TM &FLAG,L'&FLAG TEST FLAG BIT(s)
MEND

[Peter Relson]

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 one of the following:
F1 DS B
F1B0 EQU F1,X'80'
F1B1 EQU *-1,X'40'
F1B2 EQU *-L'F1,X'20'

Peter Relson
z/OS Core Technology Design

[Seymour J Metz]

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.

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Peter Relson <rel...@US.IBM.COM>
Sent: Wednesday, August 16, 2023 8:24 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

I'd think that many would find it strange to have the equates precede the field definition.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@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" <ASSEMBL...@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?

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/16/2023 10:05:25 AM:

> I can see that point.

So, now my three macros follow this pattern -- pending further
recommendations. Thanks.

MACRO
&LABEL TF &FLAG,&BAD TEST FLAG BIT(S)
AIF (T'&BAD EQ 'O').GOOD
MNOTE 12,'TOO MANY OPERANDS SPECIFIED'
MEXIT
.GOOD AIF (T'&FLAG NE 'O').BEGIN
MNOTE 12,'AN OPERAND IS REQUIRED'
MEXIT

.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
.* This is a simple macro to make it easier to accurately manipulate *
.* a bit flag definition just by the equated bit mask name -- i.e., *

.* the macro does not need to know the name of the actual flag byte *
.* nor the flag byte even have to have a name at all. *

.* *
.* As presented by the late Dr. John Ehrman of IBM at SHARE. *
.* *

.* The idea is, you can have a definition similar to either of the *
.* following. The actual flag byte does not need a name but you can *
.* specify one if you want it to show up in the cross-reference or *
.* if you want the equated bit masks to follow the flag byte def- *
.* inition. The equated bit masks then take on the location of the *
.* flag byte and the length of the equated bit mask is set to the *
.* bit mask, itself. *

.* *
.* FLAG1 EQU *,B'00000001' *
.* FLAG2 EQU *,B'00000010' *
.* FLAG3 EQU *,B'00000100' *
.* FLAG4 EQU *,B'00001000' *
.* FLAG5 EQU *,B'00010000' *
.* FLAG6 EQU *,B'00100000' *
.* FLAG7 EQU *,B'01000000' *
.* FLAG8 EQU *,B'10000000' *

.* DS BL1 MY FLAG BYTE *
.* *
.* MYFLAG DS BL1 MY FLAG BYTE *
.* FLAG1 EQU MYFLAG,B'00000001' *
.* FLAG2 EQU MYFLAG,B'00000010' *
.* FLAG3 EQU MYFLAG,B'00000100' *
.* FLAG4 EQU MYFLAG,B'00001000' *
.* FLAG5 EQU MYFLAG,B'00010000' *
.* FLAG6 EQU MYFLAG,B'00100000' *
.* FLAG7 EQU MYFLAG,B'01000000' *
.* FLAG8 EQU MYFLAG,B'10000000' *

.* *
.* NOTE: See also the SF macro and the CF macro. *
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

.BEGIN ANOP

&LABEL TM &FLAG,L'&FLAG TEST FLAG BIT(s)
MEND

[Steve Smith]

I don't object to using the length attribute this way, but with another
macro, you can avoid that. We have a set of macros that define, test, set,
or clear flags very easily, but use a definition macro works like so:
&name @FLAG &value
&name._A EQU *-1
&name._V EQU &value

The other macros look like (e.g.):
@SETFLAG FLAGX
and generate:
OI FLAGX_A,FLAGX_V

@CLRFLAG would produce NI FLAGX_A,255-FLAG_V (of course).
You still have to code a DC B or something before the @FLAG macros,
labelled or not. So, otherwise it works the same as using the length
attribute.

There are slight pros & cons to each, so I guess it comes down to
preference or possibly local standards.

sas



On Wed, Aug 16, 2023 at 10:08 AM Dave Clark <dlc...@winsupplyinc.com>
wrote:

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/16/2023 11:23:52 AM:

> I don't object to using the length attribute this way, but with another
> macro, you can avoid that. We have a set of macros that define, test,
set,
> or clear flags very easily, but use a definition macro works like so:
> &name @FLAG &value
> &name._A EQU *-1
> &name._V EQU &value

I did get one thing out of that... I need to create a macro to
define the mask flags -- since they use an unexpected equate format. I
created my definition macro to generate either relative mask flags (that
have an unnamed base location assuming an immediately prior 1-byte flag
field definition) or absolute mask flags (that have a named base location
allowing for a multi-byte flag field definition using BASE+0, BASE+1,
BASE+2, etc.). Thanks.

MACRO
&FLAG DF &MASK,&BASE,&BAD DEFINE FLAG BIT(s)
...

[John Dravnieks]

https://bitsavers.org/pdf/ibm/share/Ehrman_-_Assembler_Language_as_a_Higher_Level_Language_SHARE_Summer_2002.pdf
This is the presentation that Abe is referring to.

Kind regards
John

[Abe Kornelis]

John,

that is correct. Thank you for providing a pointer.
I was under the assumption it was no longer available on the web.

I still view this document as very instructive.
My copy is close at hand, like PoP and HLASM Lang Ref.

Actually, this presentation inspired me to create what I call
extended assembly language (CBT file 884)

I'll probably need to retire before I'll around to add
the programs that I created using extended asm.

I hope you'll all enjoy reading the document as much I did!

Kind regards & happy programming,
Abe
===


Op 17/08/2023 om 04:44 schreef John Dravnieks:

[Seymour J Metz]

With some extra work, you could do something like this

NAME FLAGS FOO+BAZ
FOO FLAG X'80'
BAR FLAG X'40'
BAZ FLAG X'20'
...
FON BAR+BAZ
...
FOFF FOO
...
FTM FOO+BAR

or even this


NAME FLAGS HH,[FOO+BAZ]
* STORAGE - Generate DC AL1, use storage immediate
* HH - Optional DC AL2, use register immediate
* HL - Optional DC AL2, use register immediate
* LH - Optional DC AL2, use register immediate
* LL - Optional DC AL2, use register immediate
FOO FLAG X'80'
BAR FLAG X'40'
BAZ FLAG X'20'
...
MYINIT FDC FOO+BAZ
...
FON BAR+BAZ,REG=MYREG
...
FOFF FOO,REG=MYREG
...
FTM FOO+BAR,REG=MYREG

or even count bits automatically.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Steve Smith [sas...@GMAIL.COM]
Sent: Wednesday, August 16, 2023 11:23 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

[Steve Smith]

Yeah, I was hesitant to go there on this thread, but I have a couple of
flag-intense programs that maintain them in a register (I think of it as my
"control" register). The register immediate instructions provide all the
same operations, with the bonus they operate on 16 bits each. Helper
macros would be more complex, but presumably save the trouble of having to
remember whether HH, HL, LH, or LL was needed for each particular flag. As
Shmuel said,...

For the record, I coded it all without creating such macros (maybe next
time).

Note that one possible drawback of all these schemes is they don't easily
support multiple bit operations. But that's typically not important.

sas

[Peter Relson]

Dave Clark asked

> Where do you draw the line?

You really don't have to draw a line. You give the macro user a way to say "don't do this checking". You're not trying to "prevent", you're trying to "help". So if there's a need to do something other than you've accommodated, let it happen.

Some z/OS system commands have an "OK" option which can be used to indicate (for example) "normally, you would prompt to confirm that I know what I'm doing, but since I do know what I'm doing, I'm telling you not to bother asking" because it can be easier not having to deal with a WTOR to respond to. Here, some "CHECK=NO" option would indicate similarly "I do know what I'm doing".

[Seymour J Metz]

Multi-bit operations just take a little bit of additional parsing and error checking in the macros. Of course, that's not worth doing if you're never going to need them.

I was assuming that the flags wouldn't always be in the same register. If they are, then the macro could also determine the register implicitly.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Steve Smith [sas...@GMAIL.COM]

Sent: Thursday, August 17, 2023 10:06 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/17/2023 10:06:50 AM:

> Note that one possible drawback of all these schemes is they don't
easily
> support multiple bit operations. But that's typically not important.

Please explain to me what you mean by "multiple bit operations".
Thanks. To me, it just sounds like a bit mask that has more than one bit
set (and to test) at the same time. But I don't see how this scenario
doesn't support that -- as it is all part of the same mask-- so, you must
be talking about something else. ;-)

[Seymour J Metz]

I assume that something like my "BAR+BAZ" requires parsing out the individual names and processing each separately. It's easy conceptually, but it definitely requires more code in the macros.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlc...@WINSUPPLYINC.COM]
Sent: Thursday, August 17, 2023 11:43 AM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Self-documenting Bit Settings

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/17/2023 11:51:39 AM:

> I assume that something like my "BAR+BAZ" requires parsing out the
> individual names and processing each separately. It's easy
> conceptually, but it definitely requires more code in the macros.

OK, I'd call that multiple masks. Thanks.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

08/16/2023 10:05:25 AM:

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

Now that I'm using my own macro (DF) to generate the equated bit
mask, how does the assembler community feel about using expression-3 in
the EQUate instruction to define a custom data type that is not one of the
28 IBM-defined data types? The manual states that this value can be 0 to
255. Do I want to require that the DF macro be used if you're going to
use the SF, CF, and TF macros -- by testing for a unique data type
assigned by the DF macro? If so, any guidelines for selecting a unique
data type designation? Note that the programmer would still be able to
use whatever format (binary, hexadecimal, character, numeric, etc) for the
bit mask operand of the DF macro, but the DF macro would assign its own
(override the) data type for the resulting equated bit mask.