Define Flag (DF) Macro

[Dave Clark]

Sorry, I shouldn't keep using that other thread since we are no
longer talking about the original subject. Anyway...

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.


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

[Steve Smith]

I think the "program type value" would be more appropriate for that
purpose. Although I don't see much benefit as stated, maybe it could lead
to some.

sas

On Thu, Aug 17, 2023 at 12:19 PM Dave Clark <dlc...@winsupplyinc.com>
wrote:

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
08/17/2023 01:46:42 PM:

> I think the "program type value" would be more appropriate for that
> purpose. Although I don't see much benefit as stated, maybe it could
lead
> to some.

OK, I'm game to do something new. I can define it in the DF macro
but I don't know how to test for it in the other three macros. Hint?

As to the benefit, I see it as a way to make sure that the
supplied bit mask was correctly defined with the location as the value and
the bit mask as the length. Since this is a non-standard way of defining
a bit mask, I want some way of making sure that the operand for the SF,
CF, and TF macros was correctly defined.

[Dave Clark]

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

08/17/2023 01:57:53 PM:

> OK, I'm game to do something new. I can define it in the DF
macro
> but I don't know how to test for it in the other three macros. Hint?

Oh, I read further and I see the SYSATTRP function will query it.
Thanks.

[Dave Clark]

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

08/17/2023 02:01:56 PM:

> Oh, I read further and I see the SYSATTRP function will query
it.
> Thanks.

I had a little trouble getting it to work. And apparently you
can't call a built-in function direction in the condition of the AIF
statement? So, is this all the correct syntax? It seems to work but I
want it to work for the right reasons and not by accident. ;-)

&TYPE SETC SYSATTRP('&FLAG')
AIF ('&TYPE' EQ 'Flag').GEN_IT
MNOTE 12,'FLAG NOT GENERATED BY DF MACRO'
MEXIT

[Jonathan Scott]

There is currently a limitation in conditional expression
processing that built-in functions with a character result are
only recognized within an expression that is already known to be
of character type. Whoever wrote the code to handle these
functions added it to the character expression parser, but the
parser for a logical expression normally expects values to be
logical or arithmetic values unless they start with a quote.

This can be worked around by ensuring that the comparison starts
with something which is clearly a character value, for example:

AIF ('Flag' EQ SYSATTRP('&FLAG')).GEN_IT
or
AIF (''.SYSATTRP('&FLAG') EQ 'Flag').GEN_IT

I wouldn't use the program type value for this special case.
I feel it is more appropriate to use it as part of a systematic
data typing scheme, for example for debugging tools. And I feel
that the constraint of needing the definition to precede the
reference is an unnecessary complication.

Jonathan Scott, HLASM
IBM, Hursley

[Dave Clark]

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

08/18/2023 04:10:51 AM:

> This can be worked around by ensuring that the comparison starts
> with something which is clearly a character value, for example:
>
> AIF ('Flag' EQ SYSATTRP('&FLAG')).GEN_IT
> or
> AIF (''.SYSATTRP('&FLAG') EQ 'Flag').GEN_IT
>

Thanks for that.

> I wouldn't use the program type value for this special case.
> I feel it is more appropriate to use it as part of a systematic
> data typing scheme, for example for debugging tools.

So, given that the other macros need to validate that the bit mask
flag was defined correctly, what would you say is the best method for
accomplishing that? ... a custom data type code different from the
IBM-defined standard ones? ...or, what?

> And I feel that the constraint of needing the definition to
> precede the reference is an unnecessary complication.

That isn't a constraint. My DF macro allows either situation --
the flag byte immediately precedes the bit masks OR the flag byte is named
and can be anywhere before or *after* the bit masks and locatable at
compile time. Meaning, my DF macro accepts an optional parameter that
names the flag byte.

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



>

> Jonathan Scott, HLASM
> IBM, Hursley

[Jonathan Scott]

Dave Clark writes:
> So, given that the other macros need to validate that the bit mask
> flag was defined correctly, what would you say is the best method for
> accomplishing that? ... a custom data type code different from the
> IBM-defined standard ones? ...or, what?

I would be personally be quite hesitant about whether such a
sophisticated solution is really required in this case. The
HLASM internal flag definitions do not use a macro, and the
macros to test, set and clear a flag are effectively one line
each. Once a programmer understands the convention, it is all
very simple.

However, I would agree that a custom data type might be a
suitable solution, for example a lower case letter.

Normally, the type attribute has the advantage that forward
references to definitions in open code will be resolved
automatically by lookahead processing. However, if the flag is
being generated by a macro, this advantage of the type attribute
will be lost.

Jonathan Scott, HLASM
IBM Hursley, UK

[Dave Clark]

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

08/19/2023 11:34:03 AM:

> However, I would agree that a custom data type might be a
> suitable solution, for example a lower case letter.

Thanks.

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

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
08/19/2023 11:34:03 AM:

> Normally, the type attribute has the advantage that forward
> references to definitions in open code will be resolved
> automatically by lookahead processing. However, if the flag is
> being generated by a macro, this advantage of the type attribute
> will be lost.

If I understand what you're really saying... My solution won't
work if the old practice is used of placing the data (and therefore the
generated EQUates) at the end of the CSECT? So, I tried that scenario and
you're correct. I guess I'll just have to drop that validation.