Re: Annoyance with the IEZJSAB macro
TRT is just one of a handful of instructions that modify all (or in the
case of TRT) some of R2.
===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===
From:
Mike Schwab mike.a.sch...@gmail.com
To:
IBM-MAIN@bama.ua.edu
Date:
07/08/2011 04:13 PM
Subject:
Re: Annoyance with the IEZJSAB macro
Sent by:
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Doesn't the TRanslate and Test instruction set R2 to an address?
On Fri, Jul 8, 2011 at 3:42 PM, Rick Fochtman rfocht...@ync.net wrote:
Ted MacNEIL wrote:
When I learned Assembler, I was taught that registers 1,1,14 and 15
could
NEVER be expected to remain unchanged accross a macro invokation.
Where is the second R1 maintained?
(8-{]}
Pardon me; I meant R0. Finger check? :-)
Rick
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Sat, 9 Jul 2011 11:50:19 -0700, Edward Jaffe wrote: While I'll readily admit there might others, this is the first and only one I've heard of that does this. I looked. I find 30 macros in SYS1.MACLIB that issue USING. 5 of them use PUSH/POP. A few of them leave the USING in effect when they end. The problem that occurs because of the lack of PUSH/POP is an assembly error. IMO this is far better than the result if the USING remains in effect but the register contents have changed. I remain unconvinced that PUSH/POP is appropriate when the register contents are not restored. I might go so far as to contend that whenever a macro alters registers 1, 14 or 15 it should issue a DROP for those registers if there is an active USING. Unfortunately, AFAIK, there is no way to do that. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Mon, 11 Jul 2011 08:53:31 -0500, Tom Marchant wrote: I looked. I find 30 macros in SYS1.MACLIB that issue USING. 5 of them use PUSH/POP. A few of them leave the USING in effect when they end. The problem that occurs because of the lack of PUSH/POP is an assembly error. IMO this is far better than the result if the USING remains in effect but the register contents have changed. Again, it depends on what programmers are accustomed to. If, magically overnight, the relevant DROP were added to every macro in SYS1.MACLIB that alters a register, would it be an immediate boon or a bane to the assembler programmer community? I remain unconvinced. I remain unconvinced that PUSH/POP is appropriate when the register contents are not restored. I might go so far as to contend that whenever a macro alters registers 1, 14 or 15 it should issue a DROP for those registers if there is an active USING. Unfortunately, AFAIK, there is no way to do that. If it were desirable, how about: USING 0,1,14,15 (Fewer, ad lib.) DROP 1,14,15 ... ? Of course, if the caller has a bracketing PUSH/POP to encapsulate a USING for another register, that POP willy-nilly restores the USING for R1. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In 3636987791660692.wa.paulgboulderaim@bama.ua.edu, on 07/11/2011 at 09:40 AM, Paul Gilmartin paulgboul...@aim.com said: Again, it depends on what programmers are accustomed to. If, magically overnight, the relevant DROP were added to every macro in SYS1.MACLIB that alters a register, would it be an immediate boon or a bane to the assembler programmer community? That's reminiscent of a lot of programs that worked[1] in OS/360 bot got ABEND S0C4 in OS/VS1. I would be willing to bet that adding the DROP statements would have a similar effect. [1] They sometimes got incorrect output, but didn't ABEND -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In p06240800ca3eb2ceae91@[192.168.1.11], on 07/09/2011 at 10:04 PM, Robert A. Rosenberg hal9...@panix.com said: If the macro takes it upon itself to issue a USING on one of the 4 linkage registers [instead of just using the usual Value-DSECT(Register) displacement addressing] it should clean up after itself by using PUSH/POP I would consider that harmful. If you want consistency, then any macro altering a register should issue a DROP. or at least document that it will destroy not only the pre-call Register Contents (as it is allowed to do due to the designation of R14-R1 as Linkage Registers) but any pre-call USINGs that were in effect. There we almost agree; I would be satisfied with a generic statement that any macro altering a register might also issue a DROP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
When I learned Assembler, I was taught that registers 0,1,14 and 15 could NEVER be expected to remain unchanged accross a macro invokation. If I may say so, the lesson was a bit incomplete. To be more correct, change the word never to not and add unless the macro documented otherwise. And of course any macro might document non-standard linkage conventions (such as SETLOCK which by default modifies registers 11,12,13) that the user must accommodate. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
snip When I learned Assembler, I was taught that registers 0,1,14 and 15 could NEVER be expected to remain unchanged accross a macro invokation. If I may say so, the lesson was a bit incomplete. To be more correct, change the word never to not and add unless the macro documented otherwise. And of course any macro might document non-standard linkage conventions (such as SETLOCK which by default modifies registers 11,12,13) that the user must accommodate. Peter Relson z/OS Core Technology Design --unsnip I won't disagree with you, Peter, but my lesson was delivered when OS/360 R16.6 was the lastest thing on the street. The next lesson came via OJT: There's no excuse for not reading the doc. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Fri, 8 Jul 2011 17:39:55 -0400, Robert A. Rosenberg hal9...@panix.com wrote: The fact that the contents of R14-R1 not remaining unchanged across a macro invocation is not the issue. The issue was a USING not remaining unchanged across the macro invocation. Since the user is restoring R1 after the macro the expectation is that the use of the macro should not have changed the environment. The destruction of the USING by the macro voids this expectation. If a macro changes, e.g., register 4 (with an appropriate save) and issues a USING for register 4, there would be no disagreement. In that case PUSH USING/POP USING would be needed. However, I am not convinced that it would be correct for a macro to re-establish the USING for register 1 when the contents of register 1 are known to have been changed. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Sat, 9 Jul 2011 11:11:19 -0500, Tom Marchant m42tom-ibmm...@yahoo.com wrote: If a macro changes, e.g., register 4 (with an appropriate save) and issues a USING for register 4, there would be no disagreement. In that case PUSH USING/POP USING would be needed. However, I am not convinced that it would be correct for a macro to re-establish the USING for register 1 when the contents of register 1 are known to have been changed. The issue remains consistency. Nearly all system macros leave the USINGs in effect unchanged regardless that they change and leave changed the content of associated registers. The macro in question here is anomalous in modifying the USINGs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On 7/9/2011 10:46 AM, Paul Gilmartin wrote: The issue remains consistency. Nearly all system macros leave the USINGs in effect unchanged regardless that they change and leave changed the content of associated registers. The macro in question here is anomalous in modifying the USINGs. Agreed. While I'll readily admit there might others, this is the first and only one I've heard of that does this. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Doesn't the TRanslate and Test instruction set R2 to an address? Sometimes. :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In p06240803ca3c103edc65@[192.168.1.11], on 07/07/2011 at 09:50 PM, Robert A. Rosenberg hal9...@panix.com said: You are confusing two issues. No. There is a USING for R1 when the macro was called. I'm aware of that. This USING was destroyed by the macro when it issued its own USING without bracketing it with a PUSH/POP. I see nothing wrong with that. This has nothing to do with the macro making use of R1 Wrong. he user can restore the contents of R1 after the return from the macro by reloading the needed value. What should NOT be also needed is to reissue the USING Were somebody in a class that I was teaching to write code that loaded R1 after a macro call but did not reissue the USING, I'd subtract a few points from his grade. the macro should not be issuing its own USING without protecting the current USING via PUSH/POP. That's your opinion. IMHO the macro should not protect the USING unless it also protects the register contents. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
At 11:11 -0500 on 07/09/2011, Tom Marchant wrote about Re: Annoyance with the IEZJSAB macro: On Fri, 8 Jul 2011 17:39:55 -0400, Robert A. Rosenberg hal9...@panix.com wrote: The fact that the contents of R14-R1 not remaining unchanged across a macro invocation is not the issue. The issue was a USING not remaining unchanged across the macro invocation. Since the user is restoring R1 after the macro the expectation is that the use of the macro should not have changed the environment. The destruction of the USING by the macro voids this expectation. If a macro changes, e.g., register 4 (with an appropriate save) and issues a USING for register 4, there would be no disagreement. In that case PUSH USING/POP USING would be needed. However, I am not convinced that it would be correct for a macro to re-establish the USING for register 1 when the contents of register 1 are known to have been changed. While I agree with your statement about R4 (and protecting any USING that references R4) since the normal registers that are subject to being used by a macro (or subroutine) are only R14-R1, that usage is about the register contents being altered NOT about USINGs pointing to the register (which must be restored due to the non-standard usage of R4 via a USING). If the macro takes it upon itself to issue a USING on one of the 4 linkage registers [instead of just using the usual Value-DSECT(Register) displacement addressing] it should clean up after itself by using PUSH/POP to restore any existent USINGs on these 4 registers that were in effect when it was called or at least document that it will destroy not only the pre-call Register Contents (as it is allowed to do due to the designation of R14-R1 as Linkage Registers) but any pre-call USINGs that were in effect. Just as you save the contents of other registers (as with R4 in your example) or at least document this usage, it should either document or preserve the USINGs. Changing the R14-R1 contents across a Macro Call/Use is normal - Making use of a USING is not and thus should be done within a PUSH/POP. Issuing a PUSH/POP within the Macro when none of the 4 registers were the subject of a USING at macro call time is harmless and just good programming (as others have pointed out). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Thu, 7 Jul 2011 21:50:24 -0400 Robert A. Rosenberg hal9...@panix.com wrote: :At 6:34 PM -0400 on 7/7/11, Shmuel Metz (Seymour J.) wrote about Re: :Annoyance with the IEZJSAB macro: : :You're the one asking IBM to provide training wheels. An experience :assembler program should know to reinstate addressability R14, R15 and :R1 following any code that alters the subject register. : :You are confusing two issues. There is a USING for R1 when the macro :was called. This USING was destroyed by the macro when it issued its :own USING without bracketing it with a PUSH/POP. This has nothing to :do with the macro making use of R1 since the user can restore the :contents of R1 after the return from the macro by reloading the :needed value. What should NOT be also needed is to reissue the USING :since unless documented in the Macro definition, the macro should not :be issuing its own USING without protecting the current USING via :PUSH/POP. All the docs say that R14-R1 are subject to being modified :by the Macros NOT that USINGs on these registers are also subject to :being modified/destroyed by the macros. : :Note that DSECT mapping Macros use PUSH/POP when they modify the :PRINT settings so the state upon finishing the macro mapping is the :same as when the macro was called. This same consideration should IMO :apply to a macro hijacking the USING states. Yes, you got it. And an IBM employee on this list also got it and emailed me privately. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
--snip--- Next in importance is lowering the Astonishment Factor. programmers are accustomed to USINGs being preserved by macro invocations regardless that the associated registers are modified. I've never assumed that addressability is maintained for R14-R1 across macro invocations and have always provided a new USING if I reload one of them. --unsnip-- When I learned Assembler, I was taught that registers 1,1,14 and 15 could NEVER be expected to remain unchanged accross a macro invokation. Seemed like a sound principle at the time and I still keep it in mind. IMNSHO, this principle remains unchanged. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
When I learned Assembler, I was taught that registers 1,1,14 and 15 could
NEVER be expected to remain unchanged accross a macro invokation.
Where is the second R1 maintained?
(8-{]}
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
Ted MacNEIL wrote:
When I learned Assembler, I was taught that registers 1,1,14 and 15 could NEVER be expected to remain unchanged accross a macro invokation.
Where is the second R1 maintained?
(8-{]}
Pardon me; I meant R0. Finger check? :-)
Rick
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
Doesn't the TRanslate and Test instruction set R2 to an address?
On Fri, Jul 8, 2011 at 3:42 PM, Rick Fochtman rfocht...@ync.net wrote:
Ted MacNEIL wrote:
When I learned Assembler, I was taught that registers 1,1,14 and 15 could
NEVER be expected to remain unchanged accross a macro invokation.
Where is the second R1 maintained?
(8-{]}
Pardon me; I meant R0. Finger check? :-)
Rick
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
Yes, but I'd expect anyone using it to be familiar enough with the
instruction to know that.
Rick
---
Mike Schwab wrote:
Doesn't the TRanslate and Test instruction set R2 to an address?
On Fri, Jul 8, 2011 at 3:42 PM, Rick Fochtman rfocht...@ync.net wrote:
Ted MacNEIL wrote:
When I learned Assembler, I was taught that registers 1,1,14 and 15 could
NEVER be expected to remain unchanged accross a macro invokation.
Where is the second R1 maintained?
(8-{]}
Pardon me; I meant R0. Finger check? :-)
Rick
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
At 13:23 -0500 on 07/08/2011, Rick Fochtman wrote about Re: Annoyance with the IEZJSAB macro: --snip--- Next in importance is lowering the Astonishment Factor. programmers are accustomed to USINGs being preserved by macro invocations regardless that the associated registers are modified. I've never assumed that addressability is maintained for R14-R1 across macro invocations and have always provided a new USING if I reload one of them. --unsnip-- When I learned Assembler, I was taught that registers 1,1,14 and 15 could NEVER be expected to remain unchanged accross a macro invokation. Seemed like a sound principle at the time and I still keep it in mind. IMNSHO, this principle remains unchanged. Rick The fact that the contents of R14-R1 not remaining unchanged across a macro invocation is not the issue. The issue was a USING not remaining unchanged across the macro invocation. Since the user is restoring R1 after the macro the expectation is that the use of the macro should not have changed the environment. The destruction of the USING by the macro voids this expectation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On 7/8/2011 5:12 PM, Mike Schwab wrote: Doesn't the TRanslate and Test instruction set R2 to an address? Tsk, tsk! g TRT is not a macro. And when it alters registers, R1 is set to an address, and (low byte) of R2 to a value. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
Kidding!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
-Original Message-
From: Rick Fochtman rfocht...@ync.net
Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Date: Fri, 8 Jul 2011 15:42:52
To: IBM-MAIN@bama.ua.edu
Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Subject: Re: Annoyance with the IEZJSAB macro
Ted MacNEIL wrote:
When I learned Assembler, I was taught that registers 1,1,14 and 15 could
NEVER be expected to remain unchanged accross a macro invokation.
Where is the second R1 maintained?
(8-{]}
Pardon me; I meant R0. Finger check? :-)
Rick
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Wed, 6 Jul 2011 13:35:08 -0500 Paul Gilmartin paulgboul...@aim.com wrote: :Assembler is without training wheels. If I do not do a DROP, I do not want a :DROP. It does not matter if STORAGE, GET or IAZJSAB are issued. :Irrelevant. Analogously you might sqy that if you do not load :R1 you do not not want R1 modified. The MACRO I used was documented as potentially changing R1. If you cannot read the doc you should not be programming assembler. :And HLASM is developing the training wheels. Naming USINGs :in effect in listing page headers, warning of overlapping :USING ranges, warning of page zero references, etc. Your :justifiable pride in mastering a difficult activity should not :lead to objections to making that activity simpler. The macro issuing a DROP did not make things simpler. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In listserv%201107061335080169.0...@bama.ua.edu, on 07/06/2011 at 01:35 PM, Paul Gilmartin paulgboul...@aim.com said: Next in importance is lowering the Astonishment Factor. programmers are accustomed to USINGs being preserved by macro invocations regardless that the associated registers are modified. I've never assumed that addressability is maintained for R14-R1 across macro invocations and have always provided a new USING if I reload one of them. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In 5b99179jr0b517n81j81bk2qravs1mn...@4ax.com, on 07/06/2011 at 09:14 PM, Binyamin Dissen bdis...@dissensoftware.com said: Following your argument, any macro that alters R14-R1 should issue a DROP for those registers. No. Assembler is without training wheels. You're the one asking IBM to provide training wheels. An experience assembler program should know to reinstate addressability R14, R15 and R1 following any code that alters the subject register. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
At 6:34 PM -0400 on 7/7/11, Shmuel Metz (Seymour J.) wrote about Re: Annoyance with the IEZJSAB macro: You're the one asking IBM to provide training wheels. An experience assembler program should know to reinstate addressability R14, R15 and R1 following any code that alters the subject register. You are confusing two issues. There is a USING for R1 when the macro was called. This USING was destroyed by the macro when it issued its own USING without bracketing it with a PUSH/POP. This has nothing to do with the macro making use of R1 since the user can restore the contents of R1 after the return from the macro by reloading the needed value. What should NOT be also needed is to reissue the USING since unless documented in the Macro definition, the macro should not be issuing its own USING without protecting the current USING via PUSH/POP. All the docs say that R14-R1 are subject to being modified by the Macros NOT that USINGs on these registers are also subject to being modified/destroyed by the macros. Note that DSECT mapping Macros use PUSH/POP when they modify the PRINT settings so the state upon finishing the macro mapping is the same as when the macro was called. This same consideration should IMO apply to a macro hijacking the USING states. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
From: Robert A. Rosenberg snip Note that DSECT mapping Macros use PUSH/POP when they modify the PRINT settings so the state upon finishing the macro mapping is the same as when the macro was called. This same consideration should IMO apply to a macro hijacking the USING states. --- I agree Robert. I just don't see why the USING at all. Almost all other IBM macros don't access via USING. The IAZXJSAB references the TCB via PSATOLD-PSA(,0), STCB via TCBSTCB-TCB(14,0), and gets to the JSAB via STCBJSAB-STCB(14). Why not use TMJSABFLG1-JSAB(1),JSABNVAL instead of TMJSABFLG1,JSABNVAL etc. Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In listserv%201107050048372743.0...@bama.ua.edu, on 07/05/2011 at 12:48 AM, Paul Gilmartin paulgboul...@aim.com said: o A blanket statement in any relevant Users Guide(s) that no macro modifies any caller's setting such as USING (PRINT? Others?) without restoring it before returning to caller. I would prefer a blanket statement that no macro should be assumed to retain a simple USING for R14, R15 or R1. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
In 4vq3171fiv25v2ogpb9gr0vphj4d3g4...@4ax.com, on 07/04/2011 at 07:36 PM, Binyamin Dissen bdis...@dissensoftware.com said: Yes, as I reload R1. Why need I reissue the USING? The macro doesn't know that you are going to reload R1. IMHO it would be an error for IAZXJSAB to load a register and not drop the previous addressability unless it restored the previous register contents. If you insist on retaining a USING for R1 across IAZXJSAB, you can always use a labelled USING. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Wed, 6 Jul 2011 14:05:07 -0400 Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: :In 4vq3171fiv25v2ogpb9gr0vphj4d3g4...@4ax.com, on 07/04/2011 : at 07:36 PM, Binyamin Dissen bdis...@dissensoftware.com said: :Yes, as I reload R1. Why need I reissue the USING? :The macro doesn't know that you are going to reload R1. IMHO it would :be an error for IAZXJSAB to load a register and not drop the previous :addressability unless it restored the previous register contents. If :you insist on retaining a USING for R1 across IAZXJSAB, you can always :use a labelled USING. Following your argument, any macro that alters R14-R1 should issue a DROP for those registers. But they do not. Assembler is without training wheels. If I do not do a DROP, I do not want a DROP. It does not matter if STORAGE, GET or IAZJSAB are issued. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Wed, 6 Jul 2011 21:14:13 +0300, Binyamin Dissen wrote: On Wed, 6 Jul 2011 14:05:07 -0400 Shmuel Metz (Seymour J.) wrote: :Yes, as I reload R1. Why need I reissue the USING? :The macro doesn't know that you are going to reload R1. IMHO it would :be an error for IAZXJSAB to load a register and not drop the previous :addressability unless it restored the previous register contents. If :you insist on retaining a USING for R1 across IAZXJSAB, you can always :use a labelled USING. Following your argument, any macro that alters R14-R1 should issue a DROP for those registers. But they do not. Most important is documenting side effects. Generally, macros document which registers they modify. Likewise, if a macro changes the setting of USING (or PRINT, or whatever) that should be documented. Next in importance is lowering the Astonishment Factor. programmers are accustomed to USINGs being preserved by macro invocations regardless that the associated registers are modified. And they are not accustomed to inspecting the documentation to see that a USING may be DROPped. Assembler is without training wheels. If I do not do a DROP, I do not want a DROP. It does not matter if STORAGE, GET or IAZJSAB are issued. Irrelevant. Analogously you might sqy that if you do not load R1 you do not not want R1 modified. And HLASM is developing the training wheels. Naming USINGs in effect in listing page headers, warning of overlapping USING ranges, warning of page zero references, etc. Your justifiable pride in mastering a difficult activity should not lead to objections to making that activity simpler. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On 7/4/2011 3:33 PM, Edward Jaffe wrote: BTW, the macro is IAZJSAB (IAZ not IEZ). Oops. How embarrassing. I have to correct my correction... :-[ The macro under discussion is IAZXJSAB. (IAZJSAB is the mapping macro for the JSAB control block.) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Sun, 3 Jul 2011 23:29:02 +0300, Binyamin Dissen wrote: I had a USING on R1 before the macro. I realize that IEZJSAB alters the standard registers, so I did a restore of R1 after the macro. Sadly IEZJSAB does a USING and DROP on 1. It would seem to me that any macro the does a USING/DROP should bracket itself with PUSH and POP USING. I should not have to do that in open code. So you would prefer that the macro do something such as: PUSH USING (modify content of R1, as documented.) USING whatever,R1 ... POP USING MEXIT ... returning to the caller with R1 modified but the prior USING ,R1 remaining in effect? Hmmm... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Mon, 4 Jul 2011 11:15:35 -0500 Paul Gilmartin paulgboul...@aim.com wrote: :On Sun, 3 Jul 2011 23:29:02 +0300, Binyamin Dissen wrote: :I had a USING on R1 before the macro. I realize that IEZJSAB alters the :standard registers, so I did a restore of R1 after the macro. Sadly IEZJSAB :does a USING and DROP on 1. :It would seem to me that any macro the does a USING/DROP should bracket itself :with PUSH and POP USING. I should not have to do that in open code. :So you would prefer that the macro do something such as: : PUSH USING : (modify content of R1, as documented.) : USING whatever,R1 : ... : POP USING : MEXIT :... returning to the caller with R1 modified but the prior USING ,R1 :remaining in effect? Yes, as I reload R1. Why need I reissue the USING? Of course, if you want to make the case that most macros DROP R14-R1 .. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Mon, 4 Jul 2011 19:36:55 +0300, Binyamin Dissen wrote: :It would seem to me that any macro the does a USING/DROP should bracket itself :with PUSH and POP USING. I should not have to do that in open code. :So you would prefer that the macro do something such as: : PUSH USING : (modify content of R1, as documented.) : USING whatever,R1 : ... : POP USING : MEXIT :... returning to the caller with R1 modified but the prior USING ,R1 :remaining in effect? Yes, as I reload R1. Why need I reissue the USING? Of course, if you want to make the case that most macros DROP R14-R1 .. Are you averring that's the current modal behavior? I'm not an expert. I see some value in consistency. My shallow perception is that most macros (inexplicably?) eschew USING and rely on explicitly citing base registers in storage instructions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Mon, 4 Jul 2011 11:59:08 -0500 Paul Gilmartin paulgboul...@aim.com wrote: :On Mon, 4 Jul 2011 19:36:55 +0300, Binyamin Dissen wrote: ::It would seem to me that any macro the does a USING/DROP should bracket itself ::with PUSH and POP USING. I should not have to do that in open code. ::So you would prefer that the macro do something such as: :: PUSH USING :: (modify content of R1, as documented.) :: USING whatever,R1 :: ... :: POP USING :: MEXIT ::... returning to the caller with R1 modified but the prior USING ,R1 ::remaining in effect? :Yes, as I reload R1. Why need I reissue the USING? :Of course, if you want to make the case that most macros DROP R14-R1 .. :Are you averring that's the current modal behavior? I'm not :an expert. I see some value in consistency. No, it does not. Assembler does not come with training wheels. :My shallow perception is that most macros (inexplicably?) :eschew USING and rely on explicitly citing base registers :in storage instructions. Yes, they do. That is what annoyed me. I could not immediately see the cause for the assembly error in the source code. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On 7/3/2011 1:29 PM, Binyamin Dissen wrote: It would seem to me that any macro the does a USING/DROP should bracket itself with PUSH and POP USING. I should not have to do that in open code. Agreed. All of our internal macros do just that. BTW, the macro is IAZJSAB (IAZ not IEZ). -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Mon, 4 Jul 2011 15:33:13 -0700, Edward Jaffe wrote: On 7/3/2011 1:29 PM, Binyamin Dissen wrote: It would seem to me that any macro the does a USING/DROP should bracket itself with PUSH and POP USING. I should not have to do that in open code. Agreed. All of our internal macros do just that. It appears that you and Binyamin have a strong argument based on consistency with prevailing conventions. Would someone more knowledgeable than I consider an RCF requesting a clarification comprising: o A blanket statement in any relevant Users Guide(s) that no macro modifies any caller's setting such as USING (PRINT? Others?) without restoring it before returning to caller. o A similar statement that no macro issues an unbalanced PUSH or POP. o An expressed commitment that any PMR reporting a verifiable violation of these terms will be addressed by either a DOC or a FIN (or better) APAR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Annoyance with the IEZJSAB macro
On Tue, 5 Jul 2011 00:48:37 -0500, Paul Gilmartin wrote: On Mon, 4 Jul 2011 15:33:13 -0700, Edward Jaffe wrote: On 7/3/2011 1:29 PM, Binyamin Dissen wrote: It would seem to me that any macro the does a USING/DROP should bracket itself with PUSH and POP USING. I should not have to do that in open code. Agreed. All of our internal macros do just that. It appears that you and Binyamin have a strong argument based on consistency with prevailing conventions. Would someone more knowledgeable than I consider an RCF requesting a clarification comprising: o A blanket statement in any relevant Users Guide(s) that no macro modifies any caller's setting such as USING (PRINT? Others?) without restoring it before returning to caller. (I meant to add, except as documented in the RM for the individual macro.) o A similar statement that no macro issues an unbalanced PUSH or POP. o An expressed commitment that any PMR reporting a verifiable violation of these terms will be addressed by either a DOC or a FIN (or better) APAR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Annoyance with the IEZJSAB macro
I had a USING on R1 before the macro. I realize that IEZJSAB alters the standard registers, so I did a restore of R1 after the macro. Sadly IEZJSAB does a USING and DROP on 1. It would seem to me that any macro the does a USING/DROP should bracket itself with PUSH and POP USING. I should not have to do that in open code. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
