The answer comes from the POP manual. "The displacement for LA is treated as a 12-bit unsigned binary integer. The displacement for LAY is treated as a 20-bit signed binary integer."
It is perfectly legal and appropriate for the LAY to go negative. Christopher Y. Blaicher Senior Software Developer Austin Development Lab phone: 512.340.6154 mobile: 512.627.3803 fax: 512.340.6647 10431 Morado Circle Austin, TX 78759 -----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
