Weird location counter

[João Reginato]

Hi guys
Take a look in these pieces of code compiled in z/OS V2R4: (use any
proportional font like courier for better understanding)

000BCC D2A5 D100 8B94 00100 02B94 2107 MVC
WKINFO(LINFO/2),LKINFO INITIALIZE DYNALLOC
000BD2 D2A5 D1A6 8C3A 001A6 02C3A 2108 MVC
WKINFO+(LINFO/2)(LINFO/2),LKINFO+(LINFO/2)
D 100 02B94 00100 2109 USING LKINFO,WKINFO
** ASMA303W Multiple address resolutions may result from this USING and the
USING on statement number 781
000BD8 4100 D104 02B98 2110 LA R0,LKINFO+4
RB POINTER
000BDC 5000 D100 02B94 2111 ST R0,LKINFO
SAVE IT
000BE0 9680 D100 02B94 2112 OI LKINFO,X'80'
LAST RB
000BE4 4100 D118 02BAC 2113 LA R0,LKTXTIFC
1ST TEXT UNIT
000BE8 5000 D10C 02BA0 2114 ST R0,LKATXTU
SAVE IT
000BEC 4100 D128 02BBC 2115 LA R0,LKDDNP
USE THIS DDNAME
000BF0 5000 D118 02BAC 2116 ST R0,LKTXTIFC
SAVE IT
000BF4 4100 D13A 02BCE 2117 LA R0,LKDSGP
RETURN DSORG
000BF8 5000 D11C 02BB0 2118 ST R0,LKTXTIFC+4
SAVE IT
000BFC 4100 D146 02BDA 2119 LA R0,LKDSNP
RETURN DSNAME
000C00 5000 D120 02BB4 2120 ST R0,LKTXTIFC+8
SAVE IT
000C04 9680 D120 02BB4 2121 OI LKTXTIFC+8,X'80'
LAST TEXT UNIT
...
000C20 4110 D100 02B94 2129 S3DYNIOK LA R1,LKINFO
POINTS TO PARAMETERS
2130 DYNALLOC ,
RETURN DSORG & TRUE DSNAME
2131+* MACDATE Y-2 73082
000C24 0A63 2132+ SVC 99 CALL DYNAMIC
ALLOCATION
...
Up to here everything appears to be ok. But see below:
...
0017FA E3F0 D07C 0058 02B10 3486+ LY R15,=V(FDRCOMPR)
LOAD EPA
...
002A8E 5341+PATCH_AREA DS 0H
PATCH AREA
002A8E 8A8E8A908A92D000 5342+ DC 64S(*)
PATCH AREA
002A96 D002D004D006D008 ==> THE LOCATION COUNTER WAS CHANGED SUDDENLY
!!!!!!!!
002A9E D00AD00CD00ED010
002AA6 D012D014D016D018
002AAE D01AD01CD01ED020
002AB6 D022D024D026D028
002ABE D02AD02CD02ED030
002AC6 D032D034D036D038
002ACE D03AD03CD03ED040
002AD6 D042D044D046D048
002ADE D04AD04CD04ED050
002AE6 D052D054D056D058
002AEE D05AD05CD05ED060
002AF6 D062D064D066D068
002AFE D06AD06CD06ED070
002B06 D072D074D076D078
002B10 5343+ LTORG
002B10 00000000 5344 =V(FDRCOMPR)
002B14 00000000 5345 =V(FDRDCOMP)
...
Page 83
Active Usings: TLTCVAF,R2 IHADCB,R3 TASKPARM,R10 FDRIOC,R11,R9,R8
QCTDCB,R12 JFCB(X'FB4'),R12+X'4C'
DECB(X'FF0'),R12+X'10' WKAREA,R13 LKINFO(X'FFFFE56C'),R13+X'2A94'
DCBE,R15
Loc Object Code Addr1 Addr2 Stmt Source Statement
HLASM R6.0 2022/04/01 19.40
...
002B94 80002B98 29585 LKINFO DC A(*+X'80000004')
RB POINTER
002B98 1407 29586 DC
AL1(LKTXTIFC-*,S99VRBIN) LENGTH, INFORMATION VERB
002B9A 0600 29587 DC
AL1(S99MSGL0+S99GDGNT,0) FLAGS1
002B9C 0000 29588 LKERC DC AL2(0)
ERROR CODE
002B9E 0000 29589 LKIRC DC AL2(0)
INFO CODE
002BA0 00002BAC00000000 29590 LKATXTU DC A(LKTXTIFC,0)
TEXT UNIT LIST PTR, RBX
002BA8 00000000 29591 DC AL1(0,0,0,0)
FLAGS2
002BAC 00002BBC00002BCE 29592 LKTXTIFC DC
A(LKDDNP,LKDSGP,LKDSNP+X'80000000')
002BB4 80002BDA
002BB8 C4C4D5D4 29593 DC C'DDNM'
002BBC 000100010008 29594 LKDDNP DC AL2(DINDDNAM,1,8)
GET INFO FROM
002BC2 4040404040404040 29595 LKDDN DC CL8' '
DDNAME
002BCA C4E2D6D9 29596 DC C'DSOR'
002BCE 000A00010002 29597 LKDSGP DC AL2(DINRTORG,1,2)
GET INFO FROM
002BD4 0000 29598 LKDSG DC AL2(0)
DSORG
002BD6 C4E2D5D4 29599 DC C'DSNM'
002BDA 0005000100FF 29600 LKDSNP DC
AL2(DINRTDSN,1,L'TKPATHN) GET INFO FROM
002BE0 0000000000000000 29601 LKDSN DC XL(L'TKPATHN)'00'
DSNAME/PATH
002CE0 29602 DS 0H
0014C 29603 LINFO EQU *-LKINFO
LENGTH
29604
*---------------------------------------------
29605 *- DYNAMIC AREA
29606
*---------------------------------------------
000000 00000 0024C 29607 WKAREA DSECT
...
000100 29662 DS 0F
000100 29663 WKINFO DS CL(LINFO)
...
END

Take a look at the location counter following “PATCH_AREA” label and the
USING list in the header lines above.
This is a very large source program with 3 base registers: (R11, R9 and R8).

My questions are:
1. Why “LKINFO(X'FFFFE56C'),R13+X'2A94'” does show a negative location?
2. About “0017FA E3F0 D07C 0058 02B10 3486+ LY
R15,=V(FDRCOMPR)”:
That should be “0017FA E3F0 8B10 0058”. Am I right?
3. Also the patch area is wrong. Why?
4. Where am I going wrong?

Any tips will be helpful.

TIA
João

[Abe Kornelis]

Joao,

from what I see it appears that the assembler thinks you have an active
USING
with R13 pointing to the location where the S-con of D000 appears,
offset 2AA4 in the listing.

I see you do have an ASMA303W indicating overlapping USING ranges.
You do have the active USINGS in the page header, so an additional EJECT
just before the PATCH_AREA might help you to pinpoint the problem.

Kind regards,
Abe Kornelis
==========


Op 03/04/2022 om 21:02 schreef João Reginato:

[João Reginato]

I don"t think so because it will just eject the page when printed

[Charles Mills]

002A8E 5341+PATCH_AREA DS 0H PATCH AREA
002A8E 8A8E8A908A92D000 5342+ DC 64S(*) PATCH AREA
002A96 D002D004D006D008 ==> THE LOCATION COUNTER WAS CHANGED SUDDENLY
!!!!!!!!
002A9E D00AD00CD00ED010

The location counter changed by 8, no? 8 bytes of S constants?

Charles

[João Reginato]

It was using R8 as the base register +displacement and suddenly changes to
R13 as you can see in 8A92D000, ie. R8+x'A92' and then R13(RD)+x'000'

[Charles Mills]

Ah! You said location counter. You meant offset. (Not criticizing; it's just that I took you literally.)

You want to know why are the first 3 s-cons 8xxx and the remainder Dxxx?

** ASMA303W Multiple address resolutions may result is a hint. You got a whole lotta USINGs there.

LKINFO(X'FFFFE56C'),R13+X'2A94' provides a clue.

The base register changes right at 2A94 into your CSECT. That is where you told HLASM that R13 points, and HLASM always (?) chooses the smallest offset when it has multiple choices.

[Charles Mills]

I didn't realize it reading your answer, Abe, until after I wrote mine, but yes, I think I am saying the same thing you said.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Abe Kornelis
Sent: Sunday, April 3, 2022 12:29 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Weird location counter

[Tony Harminc]

On Sun, 3 Apr 2022 at 15:02, João Reginato <jb.re...@gmail.com> wrote:

> Hi guys
> Take a look in these pieces of code compiled in z/OS V2R4: (use any
> proportional font like courier for better understanding)
>
> 000BCC D2A5 D100 8B94 00100 02B94 2107 MVC
> WKINFO(LINFO/2),LKINFO INITIALIZE DYNALLOC
> 000BD2 D2A5 D1A6 8C3A 001A6 02C3A 2108 MVC
> WKINFO+(LINFO/2)(LINFO/2),LKINFO+(LINFO/2)
> D 100 02B94 00100 2109 USING LKINFO,WKINFO
> ** ASMA303W Multiple address resolutions may result from this USING and
> the USING on statement number 781

Multiple USINGs are not *wrong*, but they're rarely what you want.

I think your dependent USING has its operands reversed. What you've done is
not inherently wrong, but it's unlikely to be doing what you meant.

You are telling the assembler that the first operand can be addressed using
the address supplied by the second operand, e.g. in an ordinary USING you
would typically have

USING dsectname,Rn

For a dependent USING, instead of specifying a register directly, you
supply as the second operand a name that can already be resolved with an
existing USING, and this must eventually lead to a register+offset. But you
are supplying a name within WKAREA that will be resolved using R13 (as
shown by the Active USINGs). And what is it that you are saying you will
want resolved by this USING? It's a portion of your CSECT space starting at
+2B94.

Tony H.

[Ed Jaffe]

On 4/3/2022 2:38 PM, Charles Mills wrote:
> HLASM always (?) chooses the smallest offset when it has multiple choices.

And when the offsets are equal, it chooses the higher-numbered register...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

[Abe Kornelis]

Charles,

yes - we were saying the same thing. It seems I formulated too concise.

I always find it difficult to strike a proper balance between boring
everyone
to death with lengthy and detailed explanations on the one hand,
and short concise descriptions on the other ...

At least Joao can now go ahead and sole his problem.

Thanks for expanding on my answer ;-)

Kind regards,
Abe
===

Op 03/04/2022 om 23:39 schreef Charles Mills:

[Seymour J Metz]

Multiple labelled USINGs are often what I want and, IMHO, a lablled dependent USING would be appropriate for what the OP wants. Of course, he would also need to qualify the refereneces subject to that USING.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Tony Harminc [to...@HARMINC.COM]
Sent: Sunday, April 3, 2022 11:43 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Weird location counter

[João Reginato]

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'FFFFE56C'),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'FFFFE56C' (the same as -X'1A94')?

I don't know if I was clear enough.
TIA
João

[Tony Harminc]

On Mon, 4 Apr 2022 at 15:45, João Reginato <jb.re...@gmail.com> 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 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?

> 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.

Regardless, you can always use a labelled USING (which can also be
dependent or not) just so you can unambiguously DROP it.

> I think the simplest solution is using a register instead of a data area to map it.

No - just fix your dependent USING.

> And also why LKINFO is being shown as a negative offset in "LKINFO(X'FFFFE56C'),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.

> It should be R8+X'2A94'.
> And again why X'FFFFE56C' (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.

Tony H.

[João Reginato]

> On Mon, 4 Apr 2022 at 15:45, João Reginato <jb.re...@gmail.com> 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+ LY R2,=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'FFFFE56C'),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'FFFFE56C' (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

[Jonathan Scott]

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

[Seymour J Metz]

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 [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Jonathan Scott [jonatha...@VNET.IBM.COM]
Sent: Tuesday, April 5, 2022 5:37 AM
To: ASSEMBL...@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&amp;data=04%7C01%7Csmetz3%40gmu.edu%7C3e1b7be28a944e94d2ae08da16e7fc96%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637847483026109859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BvEsUiM1w%2BVErDJNFfL9OlpxdkogTB2KVpwi6FY11p4%3D&amp;reserved=0

[Jonathan Scott]

Ref: Your note of Tue, 5 Apr 2022 12:09:44 +0000

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).