That is interesting. It is easily "fixed" by putting in a DROP 15 statement after the NOMORE1 labelled instruction. But it makes me wonder about the 20 bit offset (-Y) instructions. I'm used to the offset being a 12 bit unsigned number. Which means it ranges from 0 to 4096. For some reason, I thought the 20-bit offsets were likewise unsigned for offsets from 0 to 1048576. But it appears that they are SIGNED offsets, making them range from -524288 to 524287. So it would appear to me that HLASM was written so that a USING is now assumed to cover this entire area (or at least extends the lower limit from 0 to -524288). Sounds like the USING statement needs an enhancment to allow the specification of a lower limit since the lower limit is no longer the actual symbol.
-- 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 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 Martin Trübner > Sent: Thursday, December 30, 2010 3:01 AM > To: [email protected] > Subject: A bug or a feature? > > I have a case where HLASM creates the wrong negative offset in a LAY > instruction. > > That was at least my first thought ....when I cut the program down to > isolate the error, I found that it is caused by the rule- > "closest base > will be used" - but in my particular case I did not get an error > message at all. A "** ASMA303W Multiple address resolutions may > result.." would have been nice. > > Even better would be to make it correct. At the point the > instruction is coded, there is only one base identified via a > USING ............ > > Now is this a bug or just a "heads up"? > > Here is the reduced code: > > TITLE ' generate wrong LAY instruction' > PISNMP09 CSECT > CODE LOCTR > DEFS LOCTR > BASE DS 0D > CODE LOCTR > BAKR 14,0 > BASR 3,0 > AHI 3,BASE-* > USING BASE,3 > BASR 15,0 > TEST DC C'HERE' > ORG *+x'550' > BASR 15,0 > USING (*,NOMORE1),15 > STORAGE RELEASE,ADDR=(4),LENGTH=(0),KEY=9,SP=241 > NOMORE1 DS 0H > DS H put just a little between me and the end > * > * the following instruction uses the wrong base > * > LAY 1,TEST > LAY 1,TEST-BASE(,3) > DEFS LOCTR > * > * > LTORG > END > And before someone points out that STORAGE does not need a base. It > does in VSE (because it is too hard to copy the code from MVS to VSE). > > -- > Martin > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE > more at http://www.picapcpu.de > >
