1st time I heard that I laughed so hard I kicked the slats out of my cradle!! Duf
On Tue, Jun 19, 2012 at 11:51 AM, McKown, John < [email protected]> wrote: > Ah! I see, said the blind man. As he picked up his hammer and saw. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets® > > 9151 Boulevard 26 . N. Richland Hills . TX 76010 > (817) 255-3225 phone . > [email protected] . > www.HealthMarkets.com<http://www.healthmarkets.com/> > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets® is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company®, Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM > > > -----Original Message----- > > From: Ray Mullins [mailto:[email protected]] > > Sent: Tuesday, June 19, 2012 1:32 PM > > To: IBM Mainframe Assembler List > > Cc: McKown, John > > Subject: Re: Checking for "more restrictive" > > TYPECHECK(REGISTER) at assemble time > > > > LLH comes in at MACHINE(ZS-3), so the macro substitutes for > > LLH if assembled > > with MACHINE(ZS-2) and earlier. (O' is a nice addition.) > > > > I'm using a combination of LH and IILH (not IILL, as I wrote) > > to properly > > reflect the operation of LLH. LH wants GR32, IILH wants GR64. > > I'm working > > around that if the first operand is one of our register > > equates, but if > > someone slips something like LLH MYREG,ASCBASID where MYREG > > is tagged as GR, > > or not tagged at all, and "more restrictive" is not in > > effect, I'd like to > > bypass the code that gets the proper GR32 and GR64 EQUs. > > > > If "more restrictive" is in effect and they're using GR for their own > > equate, then screw 'em, let them deal with the ASMA323Ws. :) > > > > It's not a life-or-death situation. Let me just say that in > > what we've > > currently got now in our macro set, it would be nice to know > > when HLASM is > > in "more restrictive" mode. > > > > On 2012-06-19 09:57, McKown, John wrote: > > > I'm not entirely sure exactly what you want. But one thing > > that I do is use the Assembler parm MACHINE(architecture) to > > indicate my "highest level" instruction set. E.g. I use > > "//ASM EXEC PGM=ASMA90,PARM='MACHINE(ZSERIES-3)' to cause an > > assembler error if I were to use EXRL other instruction which > > would abend with an S0C1 on my z9BC. > > > > > > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asm > > i1020/A.2.30 > > > > > > Or is it that you want some macros to use which would > > expand to an LLH, if at the proper minimal MACHINE level, or > > to a "equivalent" set of "lower MACHINE level" instructions? > > If you want to test this, look at&SYSOPT_OPTABLE at: > > > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asm > > r1020/7.10.28 > > > > > > I don't understand the comments about LLH. Is is LLH vs. > > LLGH? And you want, somehow, to determine which to use? LLH > > should use GR32 equates and LLGH should use GR64 equates. > > > > > > -- > > > John McKown > > > Systems Engineer IV > > > IT > > > > > > Administrative Services Group > > > > > > HealthMarkets® > > > > > > 9151 Boulevard 26 . N. Richland Hills . TX 76010 > > > (817) 255-3225 phone . > > > [email protected] . > > > www.HealthMarkets.com<http://www.healthmarkets.com/> > > > > > > Confidentiality Notice: This e-mail message may contain > > confidential or proprietary information. If you are not the > > intended recipient, please contact the sender by reply e-mail > > and destroy all copies of the original message. > > HealthMarkets® is the brand name for products underwritten > > and issued by the insurance subsidiaries of HealthMarkets, > > Inc. -The Chesapeake Life Insurance Company®, Mid-West > > National Life Insurance Company of TennesseeSM and The MEGA > > Life and Health Insurance Company.SM > > > > > >> -----Original Message----- > > >> From: IBM Mainframe Assembler List > > >> [mailto:[email protected]] On Behalf Of Ray Mullins > > >> Sent: Tuesday, June 19, 2012 11:29 AM > > >> To: [email protected] > > >> Subject: Checking for "more restrictive" TYPECHECK(REGISTER) > > >> at assemble time > > >> > > >> Hi everyone, > > >> > > >> I've been through the Fine Manual and the list archives, and > > >> according to my > > >> perusal this is not possible, but I'll throw it out there to > > >> the brain trust > > >> that is ASSEMBLER-LIST. > > >> > > >> I'm working on some instruction substitution macros to catch > > >> any slips of > > >> instructions like LLH into code that for one reason or > > >> another has to be > > >> assembled with MACHINE(ZS-2), as well as better MACHINEs. In > > >> one program, we > > >> are experimenting with TYPECHECK(REGISTER) by coding two sets > > >> of equates, > > >> one GR32 and one GR64. Our one hitch is that one of these macros - > > >> specifically one for LLH, uses one instruction that wants > > GR32 and one > > >> instruction that wants GR64. (I can see why instructions like > > >> IILL want GR64 > > >> - I may not agree with it, but I can see the premise.) > > >> > > >> Our basic register equates are defined such that I can > > >> determine the GR32 > > >> and GR64 equates from the register supplied. However, it > > >> would helpful to > > >> know if HLASM has gone into its "more restrictive" type > > >> checking (their > > >> words from Appendix N from the Programmer's Guide) to add > > this extra > > >> processing, or, if not, don't bother. There's no nice > > >> &SYSOPT_ flag for > > >> TYPECHECK, nor one saying "more restrictive" has kicked in. > > >> I realize that > > >> this may be difficult, nigh impossible, depending on where in > > >> the assembly > > >> process that "more restrictive" kicks in. > > >> > > >> To handle any register equates that don't conform to our > > >> naming standard > > >> (something like CBBASE EQU R10), the oft-requested ability to > > >> SETA to an EQU > > >> value inside a macro would be wonderful. But I'm not holding > > >> my breath on > > >> that one. > > >> > > >> Short of putting in a formal enhancement request for a > > >> &SYSOPT_ or other > > >> flag (or one for TYPECHECK and one for "more restrictive" > > >> checking), or > > >> waving at Sharuff and asking if he thinks this is a good > > >> idea, does anyone > > >> have any ideas? > > >> > > >> Cheers, > > >> Ray > > >> > > >> -- > > >> M. Ray Mullins > > >> Roseville, CA, USA > > >> http://www.catherdersoftware.com/ > > >> > > >> German is essentially a form of assembly language consisting > > >> entirely of far calls heavily accented with throaty guttural > > >> sounds. ---ilvi > > >> French is essentially German with messed-up pronunciation and > > >> spelling. --Robert B Wilson > > >> English is essentially French converted to 7-bit ASCII. > > >> ---Christophe Pierret [for Alain LaBonté] > > >> > > >> > > > > > > -- > > M. Ray Mullins > > Roseville, CA, USA > > http://www.catherdersoftware.com/ > > > > German is essentially a form of assembly language consisting > > entirely of far calls heavily accented with throaty guttural > > sounds. ---ilvi > > French is essentially German with messed-up pronunciation and > > spelling. --Robert B Wilson > > English is essentially French converted to 7-bit ASCII. > > ---Christophe Pierret [for Alain LaBonté] > > > > > > >
