Re: z/OS HLASM: EQU for statement labels
I am not obligated to respond to hypocrites. Your filter is your friend; feel free to use it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of zMan [zedgarhoo...@gmail.com] Sent: Thursday, June 4, 2020 3:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Interesting definition of "profanity. In any case, still non-responsive. But getting more amusing with each iteration, as the hole gets deeper. BTW, Kerry, "PKB" is one of Metz's favorites, stands for "Pot/Kettle/Black", as in, "The pot is calling the kettle black". It passes for wit, I assume. On Thu, Jun 4, 2020 at 2:36 PM Seymour J Metz wrote: > it means that the use of profanity in complaints about courtesy are simply > hypocritical. And, BTW, more aggressive than anything I wrote. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Kerry Liles [kerry.li...@gmail.com] > Sent: Thursday, June 4, 2020 2:31 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > It seems the response was simply "PKB" > > Not sure what that means ... unlikely to stand for "I'll try to be less > aggressive" > > > > On Thu, 4 Jun 2020 at 13:57, zMan wrote: > > > Non-responsive, move to strike. > > > > On Thu, Jun 4, 2020 at 1:37 PM Seymour J Metz wrote: > > > > > PKB > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > ________ > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on > > > behalf of zMan [zedgarhoo...@gmail.com] > > > Sent: Thursday, June 4, 2020 1:36 PM > > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > > Subject: Re: z/OS HLASM: EQU for statement labels > > > > > > Somebody has to ask: Shmuel, why are you such a hostile prick? The > > smugness > > > and lack of comity you exhibit are at odds with the general tenor of > this > > > forum, and your comments--while sometimes useful--are so often just > > showing > > > off and being difficult that, were I the list owner, I'd have you on > > > moderation or banned. > > > > > > Seriously: what is the point of being such a jerk all the time? What > > > purpose does it serve you? > > > > > > > > > -- > > zMan -- "I've got a mainframe and I'm not afraid to use it" > > > -- zMan -- "I've got a mainframe and I'm not afraid to use it"
Re: z/OS HLASM: EQU for statement labels
Interesting definition of "profanity. In any case, still non-responsive. But getting more amusing with each iteration, as the hole gets deeper. BTW, Kerry, "PKB" is one of Metz's favorites, stands for "Pot/Kettle/Black", as in, "The pot is calling the kettle black". It passes for wit, I assume. On Thu, Jun 4, 2020 at 2:36 PM Seymour J Metz wrote: > it means that the use of profanity in complaints about courtesy are simply > hypocritical. And, BTW, more aggressive than anything I wrote. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Kerry Liles [kerry.li...@gmail.com] > Sent: Thursday, June 4, 2020 2:31 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > It seems the response was simply "PKB" > > Not sure what that means ... unlikely to stand for "I'll try to be less > aggressive" > > > > On Thu, 4 Jun 2020 at 13:57, zMan wrote: > > > Non-responsive, move to strike. > > > > On Thu, Jun 4, 2020 at 1:37 PM Seymour J Metz wrote: > > > > > PKB > > > > > > > > > -- > > > Shmuel (Seymour J.) Metz > > > http://mason.gmu.edu/~smetz3 > > > > > > ________ > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on > > > behalf of zMan [zedgarhoo...@gmail.com] > > > Sent: Thursday, June 4, 2020 1:36 PM > > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > > Subject: Re: z/OS HLASM: EQU for statement labels > > > > > > Somebody has to ask: Shmuel, why are you such a hostile prick? The > > smugness > > > and lack of comity you exhibit are at odds with the general tenor of > this > > > forum, and your comments--while sometimes useful--are so often just > > showing > > > off and being difficult that, were I the list owner, I'd have you on > > > moderation or banned. > > > > > > Seriously: what is the point of being such a jerk all the time? What > > > purpose does it serve you? > > > > > > > > > -- > > zMan -- "I've got a mainframe and I'm not afraid to use it" > > > -- zMan -- "I've got a mainframe and I'm not afraid to use it"
Re: z/OS HLASM: EQU for statement labels
Actually, no, no one needed to ask. This is a technical discussion board, and airing one's opinions about others' demeanor or perceived attitude are completely out-of-line and a waste of bandwidth and every subscriber's time. Everyone has opinions about the denizens of this list. There are a few regular posters that I routinely delete w/o reading. And I may be on others' plunk list. But this forum will be useless if it is clogged up with harping on each others' manners. We can figure that out individually; and ignore perceived slights from people we do not know. sas > > Somebody has to ask: Shmuel, why are you such a hostile prick? The > > smugness > > > and lack of comity you exhibit are at odds with the general tenor of > this > > > forum, and your comments--while sometimes useful--are so often just > > showing > > > off and being difficult that, were I the list owner, I'd have you on > > > moderation or banned. > > > > > > Seriously: what is the point of being such a jerk all the time? What > > > purpose does it serve you? > > > > >
Re: z/OS HLASM: EQU for statement labels
it means that the use of profanity in complaints about courtesy are simply hypocritical. And, BTW, more aggressive than anything I wrote. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Kerry Liles [kerry.li...@gmail.com] Sent: Thursday, June 4, 2020 2:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels It seems the response was simply "PKB" Not sure what that means ... unlikely to stand for "I'll try to be less aggressive" On Thu, 4 Jun 2020 at 13:57, zMan wrote: > Non-responsive, move to strike. > > On Thu, Jun 4, 2020 at 1:37 PM Seymour J Metz wrote: > > > PKB > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > > behalf of zMan [zedgarhoo...@gmail.com] > > Sent: Thursday, June 4, 2020 1:36 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: z/OS HLASM: EQU for statement labels > > > > Somebody has to ask: Shmuel, why are you such a hostile prick? The > smugness > > and lack of comity you exhibit are at odds with the general tenor of this > > forum, and your comments--while sometimes useful--are so often just > showing > > off and being difficult that, were I the list owner, I'd have you on > > moderation or banned. > > > > Seriously: what is the point of being such a jerk all the time? What > > purpose does it serve you? > > > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" >
Re: z/OS HLASM: EQU for statement labels
It seems the response was simply "PKB" Not sure what that means ... unlikely to stand for "I'll try to be less aggressive" On Thu, 4 Jun 2020 at 13:57, zMan wrote: > Non-responsive, move to strike. > > On Thu, Jun 4, 2020 at 1:37 PM Seymour J Metz wrote: > > > PKB > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > > behalf of zMan [zedgarhoo...@gmail.com] > > Sent: Thursday, June 4, 2020 1:36 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: z/OS HLASM: EQU for statement labels > > > > Somebody has to ask: Shmuel, why are you such a hostile prick? The > smugness > > and lack of comity you exhibit are at odds with the general tenor of this > > forum, and your comments--while sometimes useful--are so often just > showing > > off and being difficult that, were I the list owner, I'd have you on > > moderation or banned. > > > > Seriously: what is the point of being such a jerk all the time? What > > purpose does it serve you? > > > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" >
Re: z/OS HLASM: EQU for statement labels
Non-responsive, move to strike. On Thu, Jun 4, 2020 at 1:37 PM Seymour J Metz wrote: > PKB > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of zMan [zedgarhoo...@gmail.com] > Sent: Thursday, June 4, 2020 1:36 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > Somebody has to ask: Shmuel, why are you such a hostile prick? The smugness > and lack of comity you exhibit are at odds with the general tenor of this > forum, and your comments--while sometimes useful--are so often just showing > off and being difficult that, were I the list owner, I'd have you on > moderation or banned. > > Seriously: what is the point of being such a jerk all the time? What > purpose does it serve you? > -- zMan -- "I've got a mainframe and I'm not afraid to use it"
Re: z/OS HLASM: EQU for statement labels
Somebody has to ask: Shmuel, why are you such a hostile prick? The smugness and lack of comity you exhibit are at odds with the general tenor of this forum, and your comments--while sometimes useful--are so often just showing off and being difficult that, were I the list owner, I'd have you on moderation or banned. Seriously: what is the point of being such a jerk all the time? What purpose does it serve you?
Re: z/OS HLASM: EQU for statement labels
PKB -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of zMan [zedgarhoo...@gmail.com] Sent: Thursday, June 4, 2020 1:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Somebody has to ask: Shmuel, why are you such a hostile prick? The smugness and lack of comity you exhibit are at odds with the general tenor of this forum, and your comments--while sometimes useful--are so often just showing off and being difficult that, were I the list owner, I'd have you on moderation or banned. Seriously: what is the point of being such a jerk all the time? What purpose does it serve you?
Re: z/OS HLASM: EQU for statement labels
Maintainability. They were recommending small routine sizes before caching and paging were issues. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Doug Wegscheid [dwegsch...@sbcglobal.net] Sent: Thursday, June 4, 2020 10:00 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels please be gentle with the person relatively inexperienced with S/360 assembler. Why do they say not to use multiple base registers? cache/paging/a sign that your routine is too big to maintainable/something else? On Thu, 4 Jun 2020 12:23:18 +, Seymour J Metz wrote: >> The XPL compiler used multiple base registers. > >Yes, and in those days I was guilty as well. But eventually it sunk in why >they said not to. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3
Re: z/OS HLASM: EQU for statement labels
please be gentle with the person relatively inexperienced with S/360 assembler. Why do they say not to use multiple base registers? cache/paging/a sign that your routine is too big to maintainable/something else? On Thu, 4 Jun 2020 12:23:18 +, Seymour J Metz wrote: >> The XPL compiler used multiple base registers. > >Yes, and in those days I was guilty as well. But eventually it sunk in why >they said not to. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3
Re: z/OS HLASM: EQU for statement labels
> The XPL compiler used multiple base registers. Yes, and in those days I was guilty as well. But eventually it sunk in why they said not to. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Robin Vowels [robi...@dodo.com.au] Sent: Wednesday, June 3, 2020 7:48 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels From: "Seymour J Metz" To: Sent: Wednesday, June 03, 2020 7:00 AM > Paging? The conventional wisdom has always been to stay within one base > register, The XPL compiler used multiple base registers. > so for systems with 4K pages that isn't an issue. I tend to use LOCTR so that > constants aren't > always at the end of the source code. I normally put labels on the same line > as the instructions > and inserting code has never been a problem. I will admit to using > self-modifying code when I was > a callow youth, but I stopped doing that and started making any new code > reentrant and refreshable > sometime around the end of the 1960s. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z/OS HLASM: EQU for statement labels
Your ignorance is showing. The issues with CMS UPDATE prior to XEDIT are the same as the issues with source update in SMP, while there is sound emprical evendence that he was playing buzz word bingo and hasn't a clue what BAL is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Gary Weinhold [weinh...@dkl.com] Sent: Wednesday, June 3, 2020 11:29 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Pot, kettle On 2020-06-03 11:18 a.m., Seymour J Metz wrote: >> O my. Are you subscribing to some arcane definition of Basic Assembler >> Language that requires hand-punching cards on a Jacquard loom or something? > No. RYFM. > >> I'd suggest that it appears you've never actually supported code using CMS >> UPDATE, > ROTF,LMAO! I'd suggest that you haven't a clue about what anybody else's > experience is. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://secure-web.cisco.com/1A8TgC48H0L61Vdl0kgjFnfKlEt7a7zfXjlFJNWTobz1b7_RGwowTKIgpHEhS78YlXwwAL0m4Z3DrNMlemWm3GQ7rqWzSkM1dW1jh0BP9OqUpS4Dqfh6vHZgEcvvYJV7XAllpPkpIb8BbVpEGmBbfetFjpkJL-OC-SLQIMYsYdZx78nqBoZ4fAIl-MwUNPOPeHYARtACiBJXVFk4-j80jjCzRS6KxaA-vzg0F_VZ8BAX6nPwW5AFK6lV_HOyqYYq7TgG-oWkVLiM-Ua-XXJOi-BWfjk8b_VdnBtbQY8GSwaE5zHSMHzHpCKTXPFg6_N-ieuq54kCmLMziL5Fkk8iWM6xK7jCUXCjH8UjbOJclw2jnGp3qPjslLVqdDWLlGjGlkzvRxQgx8aLrMV8vWwy0DDR7GEdPTUL-wYQQFpFiOIAFNOO2_UB3nK-7W8Ncmh2eXbPzWIW9LPQyZf7PxoPpFw/http%3A%2F%2Fwww.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Phil Smith III [li...@akphs.com] > Sent: Wednesday, June 3, 2020 11:07 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > Metz scrawled: >>> (not writing much BAL any more). >> I doubt that you ever were, or that you've even seen it. > O my. Are you subscribing to some arcane definition of Basic Assembler > Language that requires hand-punching cards on a Jacquard loom or something? > Give me a break. > >>> I was taught not to put labels on instructions for the same reason, though >>> it was because we were using CMS UPDATE at the time, >> Non sequitor. There's nothing in UPDATE that interferes with using labels on >> instructions. BTDT,GTTS (no scars, just the tee shirt) > That's "sequitur", if we're being pedantic. > > Of course there's nothing that *interferes* with it. It's just that hygiene > means you change as little as possible, so the same issue applies as with > physical cards: if there's an instruction on a label and you need to add > something between the label and that instruction, you have to change more. > This was particularly true when hand-crafting UPDATE decks, and thus became > less of an issue once XEDIT and UPDATE mode came along, but good hygiene > continued. > > If we're going to continue the theme of being rude, I'd suggest that it > appears you've never actually supported code using CMS UPDATE, or you'd know > this. Or maybe you were just poorly taught.
Re: z/OS HLASM: EQU for statement labels
From: "Seymour J Metz" To: Sent: Wednesday, June 03, 2020 7:00 AM Paging? The conventional wisdom has always been to stay within one base register, The XPL compiler used multiple base registers. so for systems with 4K pages that isn't an issue. I tend to use LOCTR so that constants aren't always at the end of the source code. I normally put labels on the same line as the instructions and inserting code has never been a problem. I will admit to using self-modifying code when I was a callow youth, but I stopped doing that and started making any new code reentrant and refreshable sometime around the end of the 1960s. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z/OS HLASM: EQU for statement labels
Pot, kettle On 2020-06-03 11:18 a.m., Seymour J Metz wrote: O my. Are you subscribing to some arcane definition of Basic Assembler Language that requires hand-punching cards on a Jacquard loom or something? No. RYFM. I'd suggest that it appears you've never actually supported code using CMS UPDATE, ROTF,LMAO! I'd suggest that you haven't a clue about what anybody else's experience is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Wednesday, June 3, 2020 11:07 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Metz scrawled: (not writing much BAL any more). I doubt that you ever were, or that you've even seen it. O my. Are you subscribing to some arcane definition of Basic Assembler Language that requires hand-punching cards on a Jacquard loom or something? Give me a break. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, Non sequitor. There's nothing in UPDATE that interferes with using labels on instructions. BTDT,GTTS (no scars, just the tee shirt) That's "sequitur", if we're being pedantic. Of course there's nothing that *interferes* with it. It's just that hygiene means you change as little as possible, so the same issue applies as with physical cards: if there's an instruction on a label and you need to add something between the label and that instruction, you have to change more. This was particularly true when hand-crafting UPDATE decks, and thus became less of an issue once XEDIT and UPDATE mode came along, but good hygiene continued. If we're going to continue the theme of being rude, I'd suggest that it appears you've never actually supported code using CMS UPDATE, or you'd know this. Or maybe you were just poorly taught.
Re: z/OS HLASM: EQU for statement labels
> O my. Are you subscribing to some arcane definition of Basic Assembler > Language that requires hand-punching cards on a Jacquard loom or something? No. RYFM. > I'd suggest that it appears you've never actually supported code using CMS > UPDATE, ROTF,LMAO! I'd suggest that you haven't a clue about what anybody else's experience is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Wednesday, June 3, 2020 11:07 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Metz scrawled: >> (not writing much BAL any more). >I doubt that you ever were, or that you've even seen it. O my. Are you subscribing to some arcane definition of Basic Assembler Language that requires hand-punching cards on a Jacquard loom or something? Give me a break. >> I was taught not to put labels on instructions for the same reason, though >> it was because we were using CMS UPDATE at the time, >Non sequitor. There's nothing in UPDATE that interferes with using labels on >instructions. BTDT,GTTS (no scars, just the tee shirt) That's "sequitur", if we're being pedantic. Of course there's nothing that *interferes* with it. It's just that hygiene means you change as little as possible, so the same issue applies as with physical cards: if there's an instruction on a label and you need to add something between the label and that instruction, you have to change more. This was particularly true when hand-crafting UPDATE decks, and thus became less of an issue once XEDIT and UPDATE mode came along, but good hygiene continued. If we're going to continue the theme of being rude, I'd suggest that it appears you've never actually supported code using CMS UPDATE, or you'd know this. Or maybe you were just poorly taught.
Re: z/OS HLASM: EQU for statement labels
Metz scrawled: >> (not writing much BAL any more). >I doubt that you ever were, or that you've even seen it. O my. Are you subscribing to some arcane definition of Basic Assembler Language that requires hand-punching cards on a Jacquard loom or something? Give me a break. >> I was taught not to put labels on instructions for the same reason, though >> it was because we were using CMS UPDATE at the time, >Non sequitor. There's nothing in UPDATE that interferes with using labels on >instructions. BTDT,GTTS (no scars, just the tee shirt) That's "sequitur", if we're being pedantic. Of course there's nothing that *interferes* with it. It's just that hygiene means you change as little as possible, so the same issue applies as with physical cards: if there's an instruction on a label and you need to add something between the label and that instruction, you have to change more. This was particularly true when hand-crafting UPDATE decks, and thus became less of an issue once XEDIT and UPDATE mode came along, but good hygiene continued. If we're going to continue the theme of being rude, I'd suggest that it appears you've never actually supported code using CMS UPDATE, or you'd know this. Or maybe you were just poorly taught.
Re: z/OS HLASM: EQU for statement labels
- Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: Sent: Wednesday, June 03, 2020 3:26 AM Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 10:58:00, David Woolbright wrote: I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. LABELDS0H Guarantees alignment with no drawback. LABELEQU * Risks misalignment to save one keystroke in source. I was once involved with a project tnat had (like): B ENDEYECATCHER DCC'Whatever' Eyecatcher ... more data areas ... ENDEYECATCHER EQU * The eyecatcher grew to an odd number of bytes (Y2K-type problem) and code broke. Because of macro nesting, the remedy was: BENDEYECATCHER DC C'Whatever' Eyecatcher DS 0H ... more data areas ... ENDEYECATCHER EQU * STM R14,R13, === BENDEYECATCHER DC C'Whatever' Eyecatcher DS 0H ... more data areas ... DS 0H <<<<== REQUIRED HERE, NOT AS ABOVE ENDEYECATCHER EQU * STM R14,R13, === I pointed out that this introduced a needless slack byte half the time. My suggestion was overruled because of code ownership. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z/OS HLASM: EQU for statement labels
Hmmm... "I had a tough time in code review. Reviewers called me naive for using a negative value in a base register. No, the were ignorant; the code worked and was correct." Perhaps technically 'correct', in that it worked, but why run the risk of having a customer stumble over the eventual bad fruit borne of the seemingly enlightened developer decades earlier, but since maintained by lesser souls. 'Danger Will Robinson! Danger!!!' My 2 cents worth. Mike -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Tuesday, June 2, 2020 5:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Caution! This message was sent from outside your organization. Not bad. It's very useful for assembler programmers to understand the math behind 2s-complement (and how it nicely "complements" wrap-around addressing) thoroughly enough to get that; besides understanding you avoided changing the CC. But for the record, that's a negative value in an index register. sas On Tue, Jun 2, 2020 at 4:24 PM Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote: > > > > Labels... > > Even back in the 60's I was taught never to put a label on an > > instruction I only break that rule now for the subject of an EX (and > > its variants) > > > It's safer than > labelEQU * > > > Returning CC from a subroutine... > > Have to point out that IBM do this in the VSAM TESTCB macro > > > I had one co-worker who insisted on doing that. He augmented our > MVS/XA common return macro to: > > IPM > ... > SHR13,=Y(workarea_length) > ... > SPM , restore CC > > then *I* was tasked with porting to VM/370. No IPM. I did: > LH R1,=Y(-workarea_length) > LA R13,0(R1,R13) > > I had a tough time in code review. Reviewers called me naive for > using a negative value in a base register. No, the were ignorant; the > code worked and was correct. > > -- gil >
Re: z/OS HLASM: EQU for statement labels
Paging? The conventional wisdom has always been to stay within one base register, so for systems with 4K pages that isn't an issue. I tend to use LOCTR so that constants aren't always at the end of the source code. I normally put labels on the same line as the instructions and inserting code has never been a problem. I will admit to using self-modifying code when I was a callow youth, but I stopped doing that and started making any new code reentrant and refreshable sometime around the end of the 1960s. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of MELVYN MALTZ [072265160664-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 4:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Hi Guys, I thought I would put my 2 cents worth in I know that 55 years of Assembler coding doesn't count for much these days :-) Labels... Even back in the 60's I was taught never to put a label on an instruction I only break that rule now for the subject of an EX (and its variants) In the old days of real storage I used to code label EQU * and this was fine Then paging came along and the recommendation was to keep in-line data close to the instructions using it (locality of reference). As people have mentioned this sometimes resulted in odd addresses and S0C1 abends (before unalignment was detected) So I switched to label DS 0H in coding Have to state the obvious...DS 0H might not be appropriate for some data as there are now many instructions that rely on specific alignments I consider... DS 0H label EQU * to be overkill and I would deduct 2 points With changes in architecture, we now move in-line data to avoid cache problems And did you know that this code...popular in ancient times is a performance disaster now ONETIME NOP THERE MVI ONETIME+1,X'F0' Returning CC from a subroutine... Have to point out that IBM do this in the VSAM TESTCB macro Melvyn Maltz. - Original Message - From: "David Woolbright" To: Sent: Tuesday, June 02, 2020 5:58 PM Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. > On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: > >> Is this useful? > > Only if you're a sadist. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Tuesday, June 2, 2020 11:40 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > On 2020-06-02, at 09:33:48, Charles Mills wrote: >> >> I don't claim any benefit to the technique, it's just my habit. Actually >> I think the cleanest is a DS 0H followed by label EQU *. That clearly >> shows what is going on: re-establishing halfword alignment followed by >> mapping a label to an address. >> > I found it ironic that: > LABELCNOP ... > assigns the address of the beginning of the padding rather > than the end to LABEL. Is this useful? > > Fortunately, > LABELDS0H > does the opposite so your 2-instruction construct is otiose. > > -- gil
Re: z/OS HLASM: EQU for statement labels
Not bad. It's very useful for assembler programmers to understand the math behind 2s-complement (and how it nicely "complements" wrap-around addressing) thoroughly enough to get that; besides understanding you avoided changing the CC. But for the record, that's a negative value in an index register. sas On Tue, Jun 2, 2020 at 4:24 PM Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote: > > > > Labels... > > Even back in the 60's I was taught never to put a label on an instruction > > I only break that rule now for the subject of an EX (and its variants) > > > It's safer than > labelEQU * > > > Returning CC from a subroutine... > > Have to point out that IBM do this in the VSAM TESTCB macro > > > I had one co-worker who insisted on doing that. He augmented > our MVS/XA common return macro to: > > IPM > ... > SHR13,=Y(workarea_length) > ... > SPM , restore CC > > then *I* was tasked with porting to VM/370. No IPM. I did: > LH R1,=Y(-workarea_length) > LA R13,0(R1,R13) > > I had a tough time in code review. Reviewers called me > naive for using a negative value in a base register. No, > the were ignorant; the code worked and was correct. > > -- gil >
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote: > > Labels... > Even back in the 60's I was taught never to put a label on an instruction > I only break that rule now for the subject of an EX (and its variants) > It's safer than labelEQU * > Returning CC from a subroutine... > Have to point out that IBM do this in the VSAM TESTCB macro > I had one co-worker who insisted on doing that. He augmented our MVS/XA common return macro to: IPM ... SHR13,=Y(workarea_length) ... SPM , restore CC then *I* was tasked with porting to VM/370. No IPM. I did: LH R1,=Y(-workarea_length) LA R13,0(R1,R13) I had a tough time in code review. Reviewers called me naive for using a negative value in a base register. No, the were ignorant; the code worked and was correct. -- gil
Re: z/OS HLASM: EQU for statement labels
Hi Guys, I thought I would put my 2 cents worth in I know that 55 years of Assembler coding doesn't count for much these days :-) Labels... Even back in the 60's I was taught never to put a label on an instruction I only break that rule now for the subject of an EX (and its variants) In the old days of real storage I used to code label EQU * and this was fine Then paging came along and the recommendation was to keep in-line data close to the instructions using it (locality of reference). As people have mentioned this sometimes resulted in odd addresses and S0C1 abends (before unalignment was detected) So I switched to label DS 0H in coding Have to state the obvious...DS 0H might not be appropriate for some data as there are now many instructions that rely on specific alignments I consider... DS 0H label EQU * to be overkill and I would deduct 2 points With changes in architecture, we now move in-line data to avoid cache problems And did you know that this code...popular in ancient times is a performance disaster now ONETIME NOP THERE MVI ONETIME+1,X'F0' Returning CC from a subroutine... Have to point out that IBM do this in the VSAM TESTCB macro Melvyn Maltz. - Original Message - From: "David Woolbright" To: Sent: Tuesday, June 02, 2020 5:58 PM Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: Is this useful? Only if you're a sadist. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 11:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
> Imagine: My eyes! I had a bad dream, Mommy! That violates every precept of encapsulation and information hiding. A subroutine should no be tinkering with the caller's environment except in very structured ways, e.g., return codes, signals. Having code outside of a loop dealing with the loop is an invitation to disaster. But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 1:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 11:21:23, Seymour J Metz wrote: > > SIGNAL in PL/I is well behaved; in REXX, not so much. > > I like REXX, but it would have been much cleaner had iterate and leave used a > label on the do rather than using the control variable. > Yes. > It would also have been cleaner had there been a proper GOTO so that people > wouldn't shoot themselves in the foot misusing SIGNAL as an ersatz goto. > > What are long-ITERATE and long-LEAVE? > Imagine: DO LOOP = 1 CALL PROC epilogue END LOOP ... PROC: PROCEDURE EXPOSE LOOP stuff IF boolean THEN ITERATE LOOP /* bypass epilogue. */ more stuff RETURN/* to perform epilogue. */ -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote: > > I wrote an entire AVL tree based caching program using the HLASM Toolkit > Feature Structured Programming macros, but then had to rewrite to remove the > macros when the company decided to no longer pay for the feature. > > Now IBM is using the macros in IMS code, even programs where IBM provides the > source to IMS licensees. Maybe that means that if we're an IMS customer we're > also licensed for the macros. I'm kind of afraid to use them, in case we > lose access again. > I believe there's a freeware alternative. The name HAL comes to mind. But it might be in-house code. Ah! https://www.google.com/search?q=hlasm+structure+macro+hal ... points me to: www.naspa.net/magazine/2000/February/T0002006.pdf ... which mentions cbttape.org overflow file 118. -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote: > > I wrote an entire AVL tree based caching program using the HLASM Toolkit > Feature Structured Programming macros, but then had to rewrite to remove the > macros when the company decided to no longer pay for the feature. > I believe there's a freeware alternative. The name HAL comes to mind. But it might be in-house code. -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:21:23, Seymour J Metz wrote: > > SIGNAL in PL/I is well behaved; in REXX, not so much. > > I like REXX, but it would have been much cleaner had iterate and leave used a > label on the do rather than using the control variable. > Yes. > It would also have been cleaner had there been a proper GOTO so that people > wouldn't shoot themselves in the foot misusing SIGNAL as an ersatz goto. > > What are long-ITERATE and long-LEAVE? > Imagine: DO LOOP = 1 CALL PROC epilogue END LOOP ... PROC: PROCEDURE EXPOSE LOOP stuff IF boolean THEN ITERATE LOOP /* bypass epilogue. */ more stuff RETURN/* to perform epilogue. */ -- gil
Re: z/OS HLASM: EQU for statement labels
Use Concept 14 and you won't have to worry about licensing: http://skycoast.us/pscott/software/mvs/concept14.html -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Tuesday, June 2, 2020 1:30 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Tuesday, June 02, 2020 12:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do use foo DS 0H in macros, with generated labels, when it's convenient, but believes that it clutters the listing elsewhere. -- Shmuel (Seymour J.) Metz https://clicktime.symantec.com/337D3ncPndju8wuLEmAfEmP7Vc?u=http%3A%2F%2Fmason.gmu.edu%2F~smetz3 I wrote an entire AVL tree based caching program using the HLASM Toolkit Feature Structured Programming macros, but then had to rewrite to remove the macros when the company decided to no longer pay for the feature. Now IBM is using the macros in IMS code, even programs where IBM provides the source to IMS licensees. Maybe that means that if we're an IMS customer we're also licensed for the macros. I'm kind of afraid to use them, in case we lose access again. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
-Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Tuesday, June 02, 2020 12:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do use foo DS 0H in macros, with generated labels, when it's convenient, but believes that it clutters the listing elsewhere. -- Shmuel (Seymour J.) Metz https://clicktime.symantec.com/337D3ncPndju8wuLEmAfEmP7Vc?u=http%3A%2F%2Fmason.gmu.edu%2F~smetz3 I wrote an entire AVL tree based caching program using the HLASM Toolkit Feature Structured Programming macros, but then had to rewrite to remove the macros when the company decided to no longer pay for the feature. Now IBM is using the macros in IMS code, even programs where IBM provides the source to IMS licensees. Maybe that means that if we're an IMS customer we're also licensed for the macros. I'm kind of afraid to use them, in case we lose access again. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:58:00, David Woolbright wrote: > > I’’m just a humble academic so I hesitate to weigh in. I trained assembler > programmers for one large credit card processing company for many years and > their standard was to use EQU * as the target of all branches, mainly so new > lines could be added easily. I’ve never had an odd address created > accidentally using this technique, but it’s also the case that the assembler > will warn you in cases where you do have an unfavorable address. I’m in the > process of revising many years of teaching material into book format, so your > opinions on this matter to me. Using EQU for targets would seem to be a > stylistic point on which reasonable people could disagree, but perhaps I’m > wrong. > LABELDS0H Guarantees alignment with no drawback. LABELEQU * Risks misalignment to save one keystroke in source. I was once involved with a project tnat had (like): B ENDEYECATCHER DCC'Whatever' Eyecatcher ... more data areas ... ENDEYECATCHER EQU * The eyecatcher grew to an odd number of bytes (Y2K-type problem) and code broke. Because of macro nesting, the remedy was: BENDEYECATCHER DC C'Whatever' Eyecatcher DS 0H ... more data areas ... ENDEYECATCHER EQU * STM R14,R13, I pointed out that this introduced a needless slack byte half the time. My suggestion was overruled because of code ownership. -- gil
Re: z/OS HLASM: EQU for statement labels
Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do use foo DS 0H in macros, with generated labels, when it's convenient, but believes that it clutters the listing elsewhere. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Tuesday, June 2, 2020 1:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) Sorry, I was using pseudocode to illustrate a logical structure before coding it _in z/Architecture assembler_, where you have to use labels for your branch points. And it may have been a poorly contrived example because there would be a jump or branch between the two labels. Perhaps a better example is where there is an IF ... ENDIF immediately proceeding a DO ... WHILE, so that the ENDIF is at the same address as the start of the DO loop. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
SIGNAL in PL/I is well behaved; in REXX, not so much. I like REXX, but it would have been much cleaner had iterate and leave used a label on the do rather than using the control variable. It would also have been cleaner had there been a proper GOTO so that people wouldn't shoot themselves in the foot misusing SIGNAL as an ersatz goto. What are long-ITERATE and long-LEAVE? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 12:47 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) Sorry, I was using pseudocode to illustrate a logical structure before coding it _in z/Architecture assembler_, where you have to use labels for your branch points. And it may have been a poorly contrived example because there would be a jump or branch between the two labels. Perhaps a better example is where there is an IF ... ENDIF immediately proceeding a DO ... WHILE, so that the ENDIF is at the same address as the start of the DO loop. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
There are several different issues here. First, using foo EQU * instead of foo DS 0H will lead to alignment errors in programs mixing instructions and data, which is a very bad practice. Mixing LOCTR separated instructions and data, however, is a perfectly reasonable practice. Second, with any decent editor it is simple to insert and instruction after the label on another instruction. Third, if yo;re not mixing instructions and data then the difference between foo EQU * and foo DS 0H is purely stylistic. Fourth, stand alone labels will not create appropriate TEST and ADATA output. There might be a similar problem with macros that use the type of a parameter. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of David Woolbright [woolbright_da...@columbusstate.edu] Sent: Tuesday, June 2, 2020 12:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. > On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: > >> Is this useful? > > Only if you're a sadist. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Tuesday, June 2, 2020 11:40 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > On 2020-06-02, at 09:33:48, Charles Mills wrote: >> >> I don't claim any benefit to the technique, it's just my habit. Actually I >> think the cleanest is a DS 0H followed by label EQU *. That clearly shows >> what is going on: re-establishing halfword alignment followed by mapping a >> label to an address. >> > I found it ironic that: > LABELCNOP ... > assigns the address of the beginning of the padding rather > than the end to LABEL. Is this useful? > > Fortunately, > LABELDS0H > does the opposite so your 2-instruction construct is otiose. > > -- gil
Re: z/OS HLASM: EQU for statement labels
I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. > On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: > >> Is this useful? > > Only if you're a sadist. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Tuesday, June 2, 2020 11:40 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > On 2020-06-02, at 09:33:48, Charles Mills wrote: >> >> I don't claim any benefit to the technique, it's just my habit. Actually I >> think the cleanest is a DS 0H followed by label EQU *. That clearly shows >> what is going on: re-establishing halfword alignment followed by mapping a >> label to an address. >> > I found it ironic that: > LABELCNOP ... > assigns the address of the beginning of the padding rather > than the end to LABEL. Is this useful? > > Fortunately, > LABELDS0H > does the opposite so your 2-instruction construct is otiose. > > -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) -- gil
Re: z/OS HLASM: EQU for statement labels
if x if y do a foo endif bar else do b endif > Then later if you want to insert more instructions immediately before the > ELSE, it is very clear where to put them and none of the labels change. if x if y do a foo endif xcbaz,baz bar else do b endif -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Tuesday, June 2, 2020 12:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Thank you for your replies. I too was originally taught to use DS 0H for a label statement, because it guaranteed halfword instruction alignment. But I recently started using EQU * because a) it seemed to be clearer as to the intent, and b) I figured that if your instructions weren't aligned you've got bigger problems. I hadn't considered someone intentionally embedding an odd size storage area in the instruction stream without taking care to realign. I may rethink this, perhaps with Charles Mills suggestion to use DS 0H at the start of routines but continue to use EQU * inside them. As for the question of stand-alone labels vs. putting the label on the next instruction, I like the stand-alone labels because it promotes maintainable code. You can put comments on the label, but more important is that you can code multiple labels for the same address. For example, if you have this kind of structure (begging Outlook not to collapse the leading spaces): if x if y do a endif else do b endif you can code one label for the first ENDIF and another for the ELSE. Then later if you want to insert more instructions immediately before the ELSE, it is very clear where to put them and none of the labels change. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
It was a (not the only) common coding technique "in the old days" to put the fields referenced by a subroutine at the end of that subroutine. If the last field were an odd length then if the next subroutine began with label EQU * you ended up with the alignment problem referenced in these posts. Nowadays putting data near instructions is a terrible technique never minding alignment because it drives the hardware's cache management crazy. Actually you code use that technique now and avoid both alignment and caching problems through the use of LOCTR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Schmitt, Michael Sent: Tuesday, June 2, 2020 9:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Thank you for your replies. I too was originally taught to use DS 0H for a label statement, because it guaranteed halfword instruction alignment. But I recently started using EQU * because a) it seemed to be clearer as to the intent, and b) I figured that if your instructions weren't aligned you've got bigger problems. I hadn't considered someone intentionally embedding an odd size storage area in the instruction stream without taking care to realign. I may rethink this, perhaps with Charles Mills suggestion to use DS 0H at the start of routines but continue to use EQU * inside them. As for the question of stand-alone labels vs. putting the label on the next instruction, I like the stand-alone labels because it promotes maintainable code. You can put comments on the label, but more important is that you can code multiple labels for the same address. For example, if you have this kind of structure (begging Outlook not to collapse the leading spaces): if x if y do a endif else do b endif you can code one label for the first ENDIF and another for the ELSE. Then later if you want to insert more instructions immediately before the ELSE, it is very clear where to put them and none of the labels change. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
Thank you for your replies. I too was originally taught to use DS 0H for a label statement, because it guaranteed halfword instruction alignment. But I recently started using EQU * because a) it seemed to be clearer as to the intent, and b) I figured that if your instructions weren't aligned you've got bigger problems. I hadn't considered someone intentionally embedding an odd size storage area in the instruction stream without taking care to realign. I may rethink this, perhaps with Charles Mills suggestion to use DS 0H at the start of routines but continue to use EQU * inside them. As for the question of stand-alone labels vs. putting the label on the next instruction, I like the stand-alone labels because it promotes maintainable code. You can put comments on the label, but more important is that you can code multiple labels for the same address. For example, if you have this kind of structure (begging Outlook not to collapse the leading spaces): if x if y do a endif else do b endif you can code one label for the first ENDIF and another for the ELSE. Then later if you want to insert more instructions immediately before the ELSE, it is very clear where to put them and none of the labels change. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
> Is this useful? I think it is at least consistent (and yes, I know ...). I think ORG behaves the same way. > is otiose Nay, it "documents" that two functions are being performed: achieving alignment and defining a label. "not the most compact representation" is not synonymous with otiose. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, June 2, 2020 8:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: > > I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. > I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
> (not writing much BAL any more). I doubt that you ever were, or that you've even seen it. > I was taught not to put labels on instructions for the same reason, though it > was because we were using CMS UPDATE at the time, Non sequitor. There's nothing in UPDATE that interferes with using labels on instructions. BTDT,GTTS (no scars, just the tee shirt) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Tuesday, June 2, 2020 8:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
Re: z/OS HLASM: EQU for statement labels
> Is this useful? Only if you're a sadist. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 11:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: > > I don't claim any benefit to the technique, it's just my habit. Actually I > think the cleanest is a DS 0H followed by label EQU *. That clearly shows > what is going on: re-establishing halfword alignment followed by mapping a > label to an address. > I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 09:33:48, Charles Mills wrote: > > I don't claim any benefit to the technique, it's just my habit. Actually I > think the cleanest is a DS 0H followed by label EQU *. That clearly shows > what is going on: re-establishing halfword alignment followed by mapping a > label to an address. > I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Tuesday, June 2, 2020 5:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more).
Re: z/OS HLASM: EQU for statement labels
Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
Book was RE: z/OS HLASM: EQU for statement labels
> > I've been coding MVS assembler for 30 years and this is the first I've heard > of this guideline. > > Any decent text on the subject (dating from Struble's "Assembler Language > Programming > the IBM S/360" of the 1960s will point this out. Some one was asking about books and Struble is IMHO pretty good, and available for a few pounds on Abe Books UK.. Dave
Re: z/OS HLASM: EQU for statement labels
- Original Message - From: "Charles Mills" To: Sent: Tuesday, June 02, 2020 7:07 AM I use 0H if it is the beginning of a section of code and there might be an odd-length DC in front of it. But I use * when I am jumping around one instruction. Revealing my age, I got in the habit of using EQU Even in those days. using EQU could get you into trouble. rather than labeled machine instructions because if you are using punched cards and need to insert a new instruction right after the label, you only have to punch one card if you used EQU, but two if you put the label on a machine instruction. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z/OS HLASM: EQU for statement labels
- Original Message - From: "Schmitt, Michael" Sent: Tuesday, June 02, 2020 6:43 AM In John R. Ehrman's SHARE presentations on tips for modernizing IBM z/Architecture assembler programs (such as https://share.confex.com/share/120/webprogram/Handout/Session12522/modrnasm.pdf), he says that important advice from experienced assembler programmers is to: _Don't_ use EQU for statement-label creation Can anyone venture a guess as to the reason for this advice? I've been coding MVS assembler for 30 years and this is the first I've heard of this guideline. Any decent text on the subject (dating from Struble's "Assembler Language Programming the IBM S/360" of the 1960s will point this out. label EQU * preceding an instruction that does not have a label may leave you with a label having an odd-numbered address. Even if the following statement is an instruction that does have an address, label EQU * may still leave you with an odd-numbered address for 'label'. One thing I'm wondering is if the suggestion is to avoid stand alone statement labels entirely (such as LABEL EQU * or LABEL DS 0H) in favor of putting the label on the next instruction? Or is there something about EQU * that makes it a bad alternative to DS 0H? See above. EQU * is bad for those cases. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z/OS HLASM: EQU for statement labels
FSVO contemporary; it is trivial on the "archaic" SPF. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Monday, June 1, 2020 6:19 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Am 01.06.2020 um 23:07 schrieb Charles Mills: > I use 0H if it is the beginning of a section of code and there might be an > odd-length DC in front of it. But I use * when I am jumping around one > instruction. > > Revealing my age, I got in the habit of using EQU rather than labeled machine > instructions because if you are using punched cards and need to insert a new > instruction right after the label, you only have to punch one card if you > used EQU, but two if you put the label on a machine instruction. This, BTW, is true when you do editing with a contemporary editor, too. If you have the labels on separate lines, it is much easier to insert instructions or move/copy/delete instructions and not having to deal with the labels. (This is true especially for editors which support line commands). Kind regards Bernd > > Charles >
Re: z/OS HLASM: EQU for statement labels
You didn't have a 129? Yes, I know what you could do on an 029 but not on a 129, and if coerced will admit to having done it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Monday, June 1, 2020 6:22 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels > TS is your friend My 029 didn't have a TS key. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Monday, June 1, 2020 2:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels The URL is 404 compliant. Has anybody put up a web site with copies of John's work and a few words of tribute? We owe him a lot. The best reason to put the label on the instruction is that you get correct TEST and ADATA output. If you have to insert a statement after the label, TS is your friend (I don't recall the XEDIT equivalent.) If you're using vi I don't want to know ;-)
Re: z/OS HLASM: EQU for statement labels
Try this url instead for the SHARE presentation: https://www.share.org/p/do/sd/topic=206&sid=9063 It is from SHARE 120 in San Francisco (2013). You will have to login with a SHARE userid to see it though. HTH Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Monday, June 1, 2020 5:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels The URL is 404 compliant. Has anybody put up a web site with copies of John's work and a few words of tribute? We owe him a lot. The best reason to put the label on the instruction is that you get correct TEST and ADATA output. If you have to insert a statement after the label, TS is your friend (I don't recall the XEDIT equivalent.) If you're using vi I don't want to know ;-) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Monday, June 1, 2020 4:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: z/OS HLASM: EQU for statement labels In John R. Ehrman's SHARE presentations on tips for modernizing IBM z/Architecture assembler programs (such as https://secure-web.cisco.com/1MDmQPGPlhl-XBk7iLilTmlMjCPG2lHl8oCpN-lY2_t1w3z5xqh2L_s533KYfGL2uox5OiYYSYNZwzp_D_uw4BIsF2SBUbJmOtK5_O0tr9TfBM_QBPGpxnwJ_sV2-Y6wLPUBnk6-K-FKHC-nuTh-kTKAd6wRAd2oyY36o8Ibd2BAtn-Gi3fpP-Ip2uBQMrgYoDu6v3F0wz_2s9EXQR4SJtEo9CxQmgkTn2O61LXMfKcvfv_VsSdw5oRgpsY6vURQMY02y_N61YWQ61wegmZwdFGy4Nc7mBoWI-CH-SR3JNJnMWImqNDdPrpYGz1O69JlL8uQfSVhDUK4NloLrTWgbDdd916U9Bsuw54CAV7hinVicbIS6QLasiEOOsokG4rzujzsCK-G7lgGCuVu6ffG6pFFKmICzl3B_XFaQwS0shjAl7BSXRtf8jN0-Jd_Qb5Tj/https%3A%2F%2Fshare.confex.com%2Fshare%2F120%2Fwebprogram%2FHandout%2FSession12522%2Fmodrnasm.pdf%29, he says that important advice from experienced assembler programmers is to: _Don't_ use EQU for statement-label creation Can anyone venture a guess as to the reason for this advice? I've been coding MVS assembler for 30 years and this is the first I've heard of this guideline. One thing I'm wondering is if the suggestion is to avoid stand alone statement labels entirely (such as LABEL EQU * or LABEL DS 0H) in favor of putting the label on the next instruction? Or is there something about EQU * that makes it a bad alternative to DS 0H? __ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: z/OS HLASM: EQU for statement labels
> TS is your friend My 029 didn't have a TS key. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Monday, June 1, 2020 2:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels The URL is 404 compliant. Has anybody put up a web site with copies of John's work and a few words of tribute? We owe him a lot. The best reason to put the label on the instruction is that you get correct TEST and ADATA output. If you have to insert a statement after the label, TS is your friend (I don't recall the XEDIT equivalent.) If you're using vi I don't want to know ;-)
Re: z/OS HLASM: EQU for statement labels
Am 01.06.2020 um 23:07 schrieb Charles Mills: I use 0H if it is the beginning of a section of code and there might be an odd-length DC in front of it. But I use * when I am jumping around one instruction. Revealing my age, I got in the habit of using EQU rather than labeled machine instructions because if you are using punched cards and need to insert a new instruction right after the label, you only have to punch one card if you used EQU, but two if you put the label on a machine instruction. This, BTW, is true when you do editing with a contemporary editor, too. If you have the labels on separate lines, it is much easier to insert instructions or move/copy/delete instructions and not having to deal with the labels. (This is true especially for editors which support line commands). Kind regards Bernd Charles
Re: z/OS HLASM: EQU for statement labels
The URL is 404 compliant. Has anybody put up a web site with copies of John's work and a few words of tribute? We owe him a lot. The best reason to put the label on the instruction is that you get correct TEST and ADATA output. If you have to insert a statement after the label, TS is your friend (I don't recall the XEDIT equivalent.) If you're using vi I don't want to know ;-) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Monday, June 1, 2020 4:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: z/OS HLASM: EQU for statement labels In John R. Ehrman's SHARE presentations on tips for modernizing IBM z/Architecture assembler programs (such as https://secure-web.cisco.com/1MDmQPGPlhl-XBk7iLilTmlMjCPG2lHl8oCpN-lY2_t1w3z5xqh2L_s533KYfGL2uox5OiYYSYNZwzp_D_uw4BIsF2SBUbJmOtK5_O0tr9TfBM_QBPGpxnwJ_sV2-Y6wLPUBnk6-K-FKHC-nuTh-kTKAd6wRAd2oyY36o8Ibd2BAtn-Gi3fpP-Ip2uBQMrgYoDu6v3F0wz_2s9EXQR4SJtEo9CxQmgkTn2O61LXMfKcvfv_VsSdw5oRgpsY6vURQMY02y_N61YWQ61wegmZwdFGy4Nc7mBoWI-CH-SR3JNJnMWImqNDdPrpYGz1O69JlL8uQfSVhDUK4NloLrTWgbDdd916U9Bsuw54CAV7hinVicbIS6QLasiEOOsokG4rzujzsCK-G7lgGCuVu6ffG6pFFKmICzl3B_XFaQwS0shjAl7BSXRtf8jN0-Jd_Qb5Tj/https%3A%2F%2Fshare.confex.com%2Fshare%2F120%2Fwebprogram%2FHandout%2FSession12522%2Fmodrnasm.pdf%29, he says that important advice from experienced assembler programmers is to: _Don't_ use EQU for statement-label creation Can anyone venture a guess as to the reason for this advice? I've been coding MVS assembler for 30 years and this is the first I've heard of this guideline. One thing I'm wondering is if the suggestion is to avoid stand alone statement labels entirely (such as LABEL EQU * or LABEL DS 0H) in favor of putting the label on the next instruction? Or is there something about EQU * that makes it a bad alternative to DS 0H? __ Michael Schmitt | DXC.technology DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
I might have felt that way in 1960 if SOAP and TASS had an EQU statement;; I certainly didn't feel that way once I had routine access to a 3270 for my TSO sessions. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Monday, June 1, 2020 5:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I use 0H if it is the beginning of a section of code and there might be an odd-length DC in front of it. But I use * when I am jumping around one instruction. Revealing my age, I got in the habit of using EQU rather than labeled machine instructions because if you are using punched cards and need to insert a new instruction right after the label, you only have to punch one card if you used EQU, but two if you put the label on a machine instruction. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Shaw Sent: Monday, June 1, 2020 1:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I agree with Gerhard; I was taught and use labelDS0H for labels instead of EQU.
Re: z/OS HLASM: EQU for statement labels
I got out of the habit of using EQU * for labels long ago due to an assembler-level debugger (I don't remember which one now) that didn't recognize EQU labels but did recognize DS 0H labels. I have always avoided directly labelling procedural statements for the same reason you did - one less card to punch in Ye Olde Times. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Monday, June 1, 2020 5:08 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I use 0H if it is the beginning of a section of code and there might be an odd-length DC in front of it. But I use * when I am jumping around one instruction. Revealing my age, I got in the habit of using EQU rather than labeled machine instructions because if you are using punched cards and need to insert a new instruction right after the label, you only have to punch one card if you used EQU, but two if you put the label on a machine instruction. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Shaw Sent: Monday, June 1, 2020 1:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I agree with Gerhard; I was taught and use labelDS0H for labels instead of EQU. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: z/OS HLASM: EQU for statement labels
On 2020-06-01, at 15:07:33, Charles Mills wrote: > > I use 0H if it is the beginning of a section of code and there might be an > odd-length DC in front of it. But I use * when I am jumping around one > instruction. > > Revealing my age, I got in the habit of using EQU rather than labeled machine > instructions because if you are using punched cards and need to insert a new > instruction right after the label, you only have to punch one card if you > used EQU, but two if you put the label on a machine instruction. > Same with CONTINUE in FORTRAN programs. And someone once told me that GOTO continue-ending-DO skips the DO rather than branching into it. But someone may have been mistaken, or thiking wishfully. -- gil
Re: z/OS HLASM: EQU for statement labels
I use 0H if it is the beginning of a section of code and there might be an odd-length DC in front of it. But I use * when I am jumping around one instruction. Revealing my age, I got in the habit of using EQU rather than labeled machine instructions because if you are using punched cards and need to insert a new instruction right after the label, you only have to punch one card if you used EQU, but two if you put the label on a machine instruction. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Shaw Sent: Monday, June 1, 2020 1:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I agree with Gerhard; I was taught and use labelDS0H for labels instead of EQU.
Re: z/OS HLASM: EQU for statement labels
I agree with Gerhard; I was taught and use labelDS0H for labels instead of EQU. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Jun 1, 2020 at 4:46 PM Gerhard adam wrote: > > > > > Even though it may not happen often the EQU can point to an odd > address and cause the label to be referenced when it is filled with binary > zeroes (S0C1) > The use of 0H always forces boundary alignment for instructions > > > > Get Outlook for iOS > > > > > > > On Mon, Jun 1, 2020 at 1:43 PM -0700, "Schmitt, Michael" < > michael.schm...@dxc.com> wrote: > > > > > > > > > > > In John R. Ehrman's SHARE presentations on tips for modernizing IBM > z/Architecture assembler programs (such as > https://share.confex.com/share/120/webprogram/Handout/Session12522/modrnasm.pdf), > he says that important advice from experienced assembler programmers is to: > > _Don't_ use EQU for statement-label creation > > Can anyone venture a guess as to the reason for this advice? I've been > coding MVS assembler for 30 years and this is the first I've heard of this > guideline. > > One thing I'm wondering is if the suggestion is to avoid stand alone > statement labels entirely (such as LABEL EQU * or LABEL DS 0H) in favor of > putting the label on the next instruction? Or is there something about EQU > * that makes it a bad alternative to DS 0H? > > __ > Michael Schmitt | DXC.technology > > > DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, > Virginia 22102, USA. > DXC Technology Company -- This message is transmitted to you by or on > behalf of DXC Technology Company or one of its affiliates. It is intended > exclusively for the addressee. The substance of this message, along with > any attachments, may contain proprietary, confidential or privileged > information or information that is otherwise legally exempt from > disclosure. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient of this message, you are > not authorized to read, print, retain, copy or disseminate any part of this > message. If you have received this message in error, please destroy and > delete all copies and notify the sender by return e-mail. Regardless of > content, this e-mail shall not operate to bind DXC Technology Company or > any of its affiliates to any order or other contract unless pursuant to > explicit written agreement or government initiative expressly permitting > the use of e-mail for such purpose. --. >
Re: z/OS HLASM: EQU for statement labels
Even though it may not happen often the EQU can point to an odd address and cause the label to be referenced when it is filled with binary zeroes (S0C1) The use of 0H always forces boundary alignment for instructions Get Outlook for iOS On Mon, Jun 1, 2020 at 1:43 PM -0700, "Schmitt, Michael" wrote: In John R. Ehrman's SHARE presentations on tips for modernizing IBM z/Architecture assembler programs (such as https://share.confex.com/share/120/webprogram/Handout/Session12522/modrnasm.pdf), he says that important advice from experienced assembler programmers is to: _Don't_ use EQU for statement-label creation Can anyone venture a guess as to the reason for this advice? I've been coding MVS assembler for 30 years and this is the first I've heard of this guideline. One thing I'm wondering is if the suggestion is to avoid stand alone statement labels entirely (such as LABEL EQU * or LABEL DS 0H) in favor of putting the label on the next instruction? Or is there something about EQU * that makes it a bad alternative to DS 0H? __ Michael Schmitt | DXC.technology DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
