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 . john.mck...@healthmarkets.com . 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:m...@lerctr.org] > 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 . > > john.mck...@healthmarkets.com . 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ray Mullins > >> Sent: Tuesday, June 19, 2012 11:29 AM > >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > >> 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é] > > >
