Re: Define Flag (DF) Macro
"IBM Mainframe Assembler List" 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. ;-)
SETC SYSATTRP('')
AIF ('' EQ 'Flag').GEN_IT
MNOTE 12,'FLAG NOT GENERATED BY DF MACRO'
MEXIT
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.
*
Re: Define Flag (DF) Macro
"IBM Mainframe Assembler List" 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. 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. *
Re: Define Flag (DF) Macro
"IBM Mainframe Assembler List" 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. 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. *
Re: Define Flag (DF) Macro
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 wrote: > 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. > > * >
Define Flag (DF) Macro
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. *
Re: Self-documenting Bit Settings
"IBM Mainframe Assembler List" 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. 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. *
Re: Self-documenting Bit Settings
"IBM Mainframe Assembler List" 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. 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. *
Re: Self-documenting Bit Settings
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 [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlcl...@winsupplyinc.com] Sent: Thursday, August 17, 2023 11:43 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings "IBM Mainframe Assembler List" 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. ;-) 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. *
Re: Self-documenting Bit Settings
"IBM Mainframe Assembler List" 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. ;-) 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. *
Re: Self-documenting Bit Settings
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". Peter Relson z/OS Core Technology Design
Re: Self-documenting Bit Settings
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 On Thu, Aug 17, 2023 at 7:18 AM Seymour J Metz wrote: > 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 > >
Re: Self-documenting Bit Settings
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 [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Wednesday, August 16, 2023 11:23 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings 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: @FLAG _A EQU *-1 _V EQU The other macros look like (e.g.): @SETFLAG FLAGX and generate: OIFLAGX_A,FLAGX_V @CLRFLAG would produce NIFLAGX_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 wrote: > "IBM Mainframe Assembler List" 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 >TF, TEST FLAG BIT(S) > AIF (T' EQ 'O').GOOD > MNOTE 12,'TOO MANY OPERANDS SPECIFIED' > MEXIT > .GOODAIF (T' 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. * > .* * > .* FLAG1EQU *,B'0001' * > .* FLAG2EQU *,B'0010' * > .* FLAG3EQU *,B'0100' * > .* FLAG4EQU *,B'1000' * > .* FLAG5EQU *,B'0001' * > .* FLAG6EQU *,B'0010' * > .* FLAG7EQU *,B'0100' * > .* FLAG8EQU *,B'1000' * > .* DSBL1 MY FLAG BYTE * > .* * > .* MYFLAG DSBL1 MY FLAG BYTE * > .* FLAG1EQU MYFLAG,B'0001' * > .* FLAG2EQU MYFLAG,B'0010' * > .* FLAG3EQU MYFLAG,B'0100' * > .* FLAG4EQU MYFLAG,B'1000' * > .* FLAG5EQU MYFLAG,B'0001' * > .* FLAG6EQU MYFLAG,B'0010' * > .* FLAG7EQU MYFLAG,B'0100' * > .* FLAG8EQU MYFLAG,B'1000' * > .*
Re: Self-documenting Bit Settings
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: > 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
