Re: RES: Weird location counter
Ref: Your note of Tue, 5 Apr 2022 12:09:44 + Shmuel (Seymour J.) Metz writes: > What is the effect if both end and upper limit are present? That should be > documented in the reference manual. The USING statement is only used to resolve an address if all relevant constraints are satisfied. So for a reference using a 12-bit displacement, the address is checked to ensure it is greater than or equal to the first base register address and less than any end value, and if lower or upper limits are present it is also checked to ensure it is greater than or equal to any lower limit and less than any upper limit. For a 20-bit displacement, any lower and upper limits are checked, and the displacement must lie within the 20-bit signed range. The lower and upper limits are treated in a somewhat different way from the base and end values, in that if an address is outside the range of the limits then the USING statement is assumed not to apply at all, but if a 12-bit displacement is outside the range between the base and the end that may be reported as an addressability error because of being some number of bytes outside the range of the best USING statement. A documentation update is included in the APAR page, and we hope this rule should be clear from the update. The actual documentation update is still in progress (partly because we are also trying to find a workaround for some problems with mapping our example listings into the current IBM Docs style). Jonathan Scott, HLASM IBM Hursley, UK
Re: RES: Weird location counter
What is the effect if both end and upper limit are present? That should be documented in the reference manual. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jonathan Scott [jonathan_sc...@vnet.ibm.com] Sent: Tuesday, April 5, 2022 5:37 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: RES: Weird location counter This problem is a side-effect of the way in which dependent USING actually works. When you declare that field LKINFO can be based on WKINFO, you are effectively telling HLASM it can assume that R13 points to LKINFO-(WKINFO offset from R13). So when it goes past that offset, it assumes it can use R13 as a base register. There has been a requirement to do something to make this safer to use (while remaining compatible) for a very long time, and this was finally addressed by APAR PH42816 early this year. That adds new lower and upper limits on the USING statement, which apply both to 12-bit and 20-bit displacements, so you can ensure that a USING statement will not be used to address data outside the intended range. However, you should also limit the range of the overall USING for the area that includes that dependent range, otherwise you will still have multiple USINGs for the same range. For details, see the APAR page: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fapar%2FPH42816&data=04%7C01%7Csmetz3%40gmu.edu%7C3e1b7be28a944e94d2ae08da16e7fc96%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637847483026109859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BvEsUiM1w%2BVErDJNFfL9OlpxdkogTB2KVpwi6FY11p4%3D&reserved=0 The weird USING heading may be in error, in that some problems with dependent USING headers were also fixed by PH42816 and earlier APAR PH42050 (which added 20-bit displacement support for dependent USING). Jonathan Scott, HLASM IBM Hursley, UK
Re: RES: Weird location counter
This problem is a side-effect of the way in which dependent USING actually works. When you declare that field LKINFO can be based on WKINFO, you are effectively telling HLASM it can assume that R13 points to LKINFO-(WKINFO offset from R13). So when it goes past that offset, it assumes it can use R13 as a base register. There has been a requirement to do something to make this safer to use (while remaining compatible) for a very long time, and this was finally addressed by APAR PH42816 early this year. That adds new lower and upper limits on the USING statement, which apply both to 12-bit and 20-bit displacements, so you can ensure that a USING statement will not be used to address data outside the intended range. However, you should also limit the range of the overall USING for the area that includes that dependent range, otherwise you will still have multiple USINGs for the same range. For details, see the APAR page: https://www.ibm.com/support/pages/apar/PH42816 The weird USING heading may be in error, in that some problems with dependent USING headers were also fixed by PH42816 and earlier APAR PH42050 (which added 20-bit displacement support for dependent USING). Jonathan Scott, HLASM IBM Hursley, UK
RES: Weird location counter
> On Mon, 4 Apr 2022 at 15:45, João Reginato wrote: > > > > Thank you all for the comments. > > What I'm trying to do is simply to map a dynamic data area (WKINFO) using > a static one (LKINFO). > > > > Any references to data after LKINFO will be in fact referencing the dynamic > area after WKINFO instead. > I'm still convinced that your USING operands are backwards. > > You have USING LKINFO,WKINFO > but would it make any sense to write > USING R2,WKINFO ? What you have done is to tell the assembelr how to > address symbols starting at LKINFO using the addressibility it already > has to WKINFO via R13. This is not fundamentally wrong, but I'm sure > it's not what you want to accomplish. I want to repeat the same area in another place without rewrite all the fields individually. And don't spend a register for USING. > > I wonder why "USING area,map" accepts a data area as "map" but the > DROP only accepts a register. > You want "USING map,area". Same as you'd write USING CVT,R3 or the > like. Yes, you *can* use mappings that are not in a DSECT, but again, > I'm pretty sure it's not what you want to do. > Why can't you DROP with the name from the second operand of USING? > Because there's potential ambiguity - you can have multiple USINGs > covering the same area. Which one do you wnat to drop? I've tried "DROP LKINFO" and "DROP WKINFO". Both gets "** ASMA029E Incorrect register specification". I've just discovered that if I use "LKUSING USING LKINFO,WKINFO" I can use "DROP LKUSING" instead. It solved all the references after the DROP as I wanted. > > And it worked fine until that point inside the PATCH_AREA where the base > register was suddenly changed from 8 to 13. > > I have many other similar samples working properly as I expected. But they > are less complexes and smaller too. > > The error is being caused because the corresponding DROP is missing and I > don't know how to drop it. > I don't think this is your problem. Yes it is. Even the "LY R15,=V(FDRCOMP)" is getting a wrong address and I wonder what will be loaded here. 0017CE E320 D07C 0058 02B10 3468+ LYR2,=V(FDRCOMPR) It is using D07C instead of R8 as the base register. > Regardless, you can always use a labelled USING (which can also be > dependent or not) just so you can unambiguously DROP it. Now I know how. > > I think the simplest solution is using a register instead of a data area to > > map > it. > No - just fix your dependent USING. Now I know how. > > And also why LKINFO is being shown as a negative offset in > "LKINFO(X'E56C'),R13+X'2A94'" once it is defined inside the main CSECT > addressed by R8 and not in the DSECT addressed by R13. > Because you told the assembler it could address LKINFO using the > existing addressibility to WKINFO via R13. I had a wrong concept for this kind of USING. > > It should be R8+X'2A94'. > > And again why X'E56C' (the same as -X'1A94')? > > I don't know if I was clear enough. > If you would make your *entire* listing available, not skipping over > the parts you think are unimportant, and including all macro > expansions and no PRINT OFFs or NOGENs, I'm sure people will look > harder at it. Perhaps make it available on a website or something > rather than inline and wrapped. There is no need anymore. But how? Using attachments? There is a limit of 250 lines in this list. > Tony H. Thank you Tony Regards João
RES: Weird location counter
Thank you all for the comments. What I'm trying to do is simply to map a dynamic data area (WKINFO) using a static one (LKINFO). Any references to data after LKINFO will be in fact referencing the dynamic area after WKINFO instead. And it worked fine until that point inside the PATCH_AREA where the base register was suddenly changed from 8 to 13. I have many other similar samples working properly as I expected. But they are less complexes and smaller too. The error is being caused because the corresponding DROP is missing and I don't know how to drop it. I wonder why "USING area,map" accepts a data area as "map" but the DROP only accepts a register. I think the simplest solution is using a register instead of a data area to map it. And also why LKINFO is being shown as a negative offset in "LKINFO(X'E56C'),R13+X'2A94'" once it is defined inside the main CSECT addressed by R8 and not in the DSECT addressed by R13. It should be R8+X'2A94'. And again why X'E56C' (the same as -X'1A94')? I don't know if I was clear enough. TIA João
