To Gen or Not To Gen
Hello Listers! I am in the process of writing a macro and would like to control whether or not some MNOTEs are generated. What I am looking for is whether or not I can check the current status of GEN versus NOGEN. If the macro is assembled and PRINT GEN is specified, I don't want to issue my MNOTEs but if the assembly is performed with PRINT NOGEN, then I want to execute the MNOTEs. Has anyone ever done anything like this? If so, how does one test for the GEN/NOGEN status? Thanks, Chuck Charles (Chuck) Hardee Senior Systems Engineer Database Administration Information Technology Services Thermo Fisher Scientific chuck.har...@thermofisher.com
Re: Jumpify Your Code (Was: Base registers)
Ed, can I link to yours from mine? http://pi-sysprog.de/free/makerel.html or (in another language) http://pi-sysprog.de/free/makereld.html on the very end -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: To Gen or Not To Gen
There is no accessible SYS... system variable that records which of GEN|NOGEN is in effect. What you can do is use a binary/boolean set symbol that you set and reset yourself, as in | gblb suppress_mnotes | . . . |suppress_mnote setb 1 | push NOGEN . . . | . . . Then within each macro that will be expanded you will need | gblb suppress_mnotes and instances of | aif(suppress_mnotes).after_mnote_counter | mnote . . . |.after_mnote_counter anop Things like this are easy enough to do when one is writing a set of macros, but they are tedious to retrofit. John Gilmore, Ashland, MA 01721 - USA On 6/17/12, Hardee, Chuck chuck.har...@thermofisher.com wrote: Hello Listers! I am in the process of writing a macro and would like to control whether or not some MNOTEs are generated. What I am looking for is whether or not I can check the current status of GEN versus NOGEN. If the macro is assembled and PRINT GEN is specified, I don't want to issue my MNOTEs but if the assembly is performed with PRINT NOGEN, then I want to execute the MNOTEs. Has anyone ever done anything like this? If so, how does one test for the GEN/NOGEN status? Thanks, Chuck Charles (Chuck) Hardee Senior Systems Engineer Database Administration Information Technology Services Thermo Fisher Scientific chuck.har...@thermofisher.com
Re: To Gen or Not To Gen
Thanks John, I appreciate the response. Charles (Chuck) Hardee Senior Systems Engineer Database Administration Information Technology Services Thermo Fisher Scientific 300 Industry Drive Pittsburgh, PA 15275 Direct: 724-517-2633 FAX: 412-490-9230 chuck.har...@thermofisher.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Gilmore Sent: Sunday, June 17, 2012 12:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: To Gen or Not To Gen There is no accessible SYS... system variable that records which of GEN|NOGEN is in effect. What you can do is use a binary/boolean set symbol that you set and reset yourself, as in | gblb suppress_mnotes | . . . |suppress_mnote setb 1 | push NOGEN . . . | . . . Then within each macro that will be expanded you will need | gblb suppress_mnotes and instances of | aif(suppress_mnotes).after_mnote_counter | mnote . . . |.after_mnote_counter anop Things like this are easy enough to do when one is writing a set of macros, but they are tedious to retrofit. John Gilmore, Ashland, MA 01721 - USA On 6/17/12, Hardee, Chuck chuck.har...@thermofisher.com wrote: Hello Listers! I am in the process of writing a macro and would like to control whether or not some MNOTEs are generated. What I am looking for is whether or not I can check the current status of GEN versus NOGEN. If the macro is assembled and PRINT GEN is specified, I don't want to issue my MNOTEs but if the assembly is performed with PRINT NOGEN, then I want to execute the MNOTEs. Has anyone ever done anything like this? If so, how does one test for the GEN/NOGEN status? Thanks, Chuck Charles (Chuck) Hardee Senior Systems Engineer Database Administration Information Technology Services Thermo Fisher Scientific chuck.har...@thermofisher.com
Re: Jumpify Your Code (Was: Base registers)
On 6/17/2012 9:13 AM, Martin Truebner wrote: Ed, can I link to yours from mine? http://pi-sysprog.de/free/makerel.html or (in another language) http://pi-sysprog.de/free/makereld.html on the very end Of course! 8-) Your bilingual perspective (I mean VSE/MVS, not English/German ;-) ) is always highly appreciated! -- 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/
Re: Base registers
On 6/17/2012 9:05 AM, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. My favorite along these lines is stench, that did not always mean unpleasant. I vividly remember a streetcar ride where almost every passenger carried freshly cut lilacs, to the point where the smell was overpowering, though not unpleasant. Alternative suggestions? I used unbased. Gerhard Postpischil Bradford, VT
Re: To Gen or Not To Gen
On 6/17/2012 11:18 AM, Hardee, Chuck wrote: Has anyone ever done anything like this? If so, how does one test for the GEN/NOGEN status? While I haven't taken the approach suggested by Mr. Gilmore, a friend (S. Metz) started me on something related. I have three string variables, for source, local macros, system code and macros, that are set to defaults by a COPY statement, used in the deck on PRINT statements, and modifiable without source changes from the PARM field via macro. Introducing a fourth variable to keep the current state would be trivial. If I were to do this, I'd introduce a new LIST macro, otherwise identical to PRINT, to maintain the current status. Gerhard Postpischil Bradford, VT
Re: Base registers
Unbased is better by a wide margin than baseless. I should still, however, prefer a non-negative form. John Gilmore, Ashland, MA 01721 - USA On 6/17/12, Gerhard Postpischil gerh...@valley.net wrote: On 6/17/2012 9:05 AM, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. My favorite along these lines is stench, that did not always mean unpleasant. I vividly remember a streetcar ride where almost every passenger carried freshly cut lilacs, to the point where the smell was overpowering, though not unpleasant. Alternative suggestions? I used unbased. Gerhard Postpischil Bradford, VT
Re: Base registers
Why don't we jump to the underlying notion of the jump instructions, or more accurately branch relative instructions, which is relative addressing: relative address oriented programming. I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of senile changes, meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word lewd to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term jump-based, I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current vulgar mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase mobile vulgus, is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA
Proposal: Replacement for baseless code terminology
I'm not sure why baseless is raising such ire, but whatever. I would like something simple. In my coding, I use Jump, Relative Addressing and Immediate operands wherever possible. This led me to perhaps JRAIC as an acronym (Jump, Relative Addressing, Immediate Coding). Not too bad, but then my essential weirdness asserted itself. For truly solid programming, use BRICs! BranchRelativeImmediateCoding. The word Relative both related to the word Branch, and is stand alone. Better, IMO, than BRRIC. I'm not insisting on this. Just putting it out for comment to the community. -- John McKown Maranatha!
Re: Base registers
The problem is that all addresses are relative to something. Some are relative to a base register, some are relative to the current instruction. Even absolute addresses are relative to zero. ;-) How about base-free code? That sounds like a positive thing. (I avoided the temptation to to suggest freebase lest that be considered to have a negative connotation.) === Date: Sun, 17 Jun 2012 17:13:30 -0400 From: gt.ibm.li...@actionsoftware.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Why don't we jump to the underlying notion of the jump instructions, or more accurately branch relative instructions, which is relative addressing: relative address oriented programming. I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of senile changes, meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word lewd to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term jump-based, I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current vulgar mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase mobile vulgus, is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
Sorry Steve. I didn't see your post until after I posted mine. === Date: Sun, 17 Jun 2012 17:35:36 -0400 From: jayare...@hotmail.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU The problem is that all addresses are relative to something. Some are relative to a base register, some are relative to the current instruction. Even absolute addresses are relative to zero. ;-) How about base-free code? That sounds like a positive thing. (I avoided the temptation to to suggest freebase lest that be considered to have a negative connotation.) === Date: Sun, 17 Jun 2012 17:13:30 -0400 From: gt.ibm.li...@actionsoftware.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Why don't we jump to the underlying notion of the jump instructions, or more accurately branch relative instructions, which is relative addressing: relative address oriented programming. I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of senile changes, meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word lewd to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term jump-based, I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current vulgar mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase mobile vulgus, is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA
Re: Base registers
Just my two cents: 1. There are architectures which have always had relative addressing, and use that term. 2. Some day, relative braches will be the norm and not the exception. As time goes on, any term with base as the root (e.g. unbased, baseless, etc.) is likely to need increasingly superfluous explanations to novices. Thus, I suggest relative branch and/or jump should suffice. For the exclusive case (non-base register branching) perhaps relative-only branching and/or jump-only program[ming]. On Sun, Jun 17, 2012 at 5:38 PM, J R jayare...@hotmail.com wrote: Sorry Steve. I didn't see your post until after I posted mine. === Date: Sun, 17 Jun 2012 17:35:36 -0400 From: jayare...@hotmail.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU The problem is that all addresses are relative to something. Some are relative to a base register, some are relative to the current instruction. Even absolute addresses are relative to zero. ;-) How about base-free code? That sounds like a positive thing. (I avoided the temptation to to suggest freebase lest that be considered to have a negative connotation.) === Date: Sun, 17 Jun 2012 17:13:30 -0400 From: gt.ibm.li...@actionsoftware.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Why don't we jump to the underlying notion of the jump instructions, or more accurately branch relative instructions, which is relative addressing: relative address oriented programming. I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of senile changes, meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word lewd to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term jump-based, I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current vulgar mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase mobile vulgus, is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA -- OREXXMan
Re: Base registers
From: Watkins, Douglas douglas.watk...@compuware.com Sent: Wednesday, 6 June 2012 11:28 PM Here's one way to do standard EXecute without a base register: AHI R2,-1 Minus 1 for EX BTW, BCTR 2,0 will do a better job.
Re: Base registers
On Mon, 2012-06-18 at 11:24 +1000, Robin Vowels wrote: From: Watkins, Douglas douglas.watk...@compuware.com Sent: Wednesday, 6 June 2012 11:28 PM Here's one way to do standard EXecute without a base register: AHI R2,-1 Minus 1 for EX BTW, BCTR 2,0 will do a better job. I agree. It is two bytes shorter. Possibly faster. Does not disturb the condition code. And is a generally understood standard notation. Might even be considered like the DECrement instruction in other assemblers. As an aside, I was actually (foolishly) considering making macros called DEC (as in DEC Reg,Value = AHI Reg,0-Value with default of 1), INC (INC Reg,Value = AHI Reg,Value, default of 1), PRED Reg (DEC Reg,1), SUCC Reg (INC Reg). Then realized it would likely be more confusing than helpful. -- John McKown Maranatha!
Re: Base registers
On 6/17/2012 10:44 PM, John McKown wrote: As an aside, I was actually (foolishly) considering making macros called DEC (as in DEC Reg,Value = AHI Reg,0-Value with default of 1), INC (INC Reg,Value = AHI Reg,Value, default of 1), PRED Reg (DEC Reg,1), SUCC Reg (INC Reg). Then realized it would likely be more confusing than helpful. Not sure what's confusing about it; I've had an INC for ages (no DEC, instead put INC=-1 on INC - that may be confusing?). It changes either a register or storage, and had a version for halfwords named INCH g Gerhard Postpischil Bradford, VT