Binder Cross-Reference table and WXTRN

5 views
Skip to first unread message

David Eisenberg

unread,
Mar 19, 2020, 10:43:01 PM3/19/20
to ASSEMBL...@listserv.uga.edu
Hi everyone,

I'm seeing a result in the binder Cross-Reference table that looks odd; I hope that someone can help me to understand.

I have two HLASM source modules, MODULEA and MODULEB (as below). Each generates an object module.

MODULEA CSECT
WXTRN TARGET2
DC V(TARGET1)
DC V(TARGET2)
END

MODULEB CSECT
WXTRN TARGET1
DC V(TARGET1)
END

I linked these two object modules together (along with no other object modules). As expected, neither TARGET1 nor TARGET2 are resolved by the binder. But only TARGET1 generates an IEW2456E "unresolved symbol" error message, and that much I understand.

In the binder output Cross-Reference table, this is what I see:

------------- R E F E R E N C E -------------------------- T A R G E T -----
CLASS ELEMENT |
OFFSET SECT/PART(ABBREV) OFFSET TYPE | SYMBOL(ABBREV) SECTION (ABBREV)
|
0 MODULEA 0 V-CON | TARGET1 $UNRESOLVED
4 MODULEA 4 V-CON | TARGET2 $UNRESOLVED(W)
80 MODULEB 0 V-CON | TARGET1 $UNRESOLVED

What I don't understand is why TARGET1 is not reported as a *weak* unresolved reference within MODULEB. In other words, I would have expected the third entry in the table above to say $UNRESOLVED(W), because TARGET1 is declared as weak in MODULEB.

I really just want to make sure that I'm interpreting what I see correctly. Any help would be appreciated; thank you!

David

Charles Mills

unread,
Mar 19, 2020, 11:53:51 PM3/19/20
to ASSEMBL...@listserv.uga.edu
Because it is not "weak" in MODULEA. MODULEA says "I really need TARGET1." The fact that it is optional for MODULEB is irrelevant.

It's a WXTRN in MODULEA but an EXTRN in MODULEB. "Weak" is not an attribute of an entry point overall; it is an attribute of a reference to an entry point from within a particular module.

Charles

Robert Netzlof

unread,
Mar 19, 2020, 11:55:45 PM3/19/20
to ASSEMBL...@listserv.uga.edu
Take what I say with a grain of salt.

Since one of the modules does not define TARGET1 as weak, then it can
not be treated as weak anywhere.

Bob Netzlof
--
Bob Netzlof a/k/a Sweet Old Bob

Martin Trübner

unread,
Mar 20, 2020, 1:05:39 AM3/20/20
to ASSEMBL...@listserv.uga.edu
Or in other word Weak=the code can handle a "not resolved" conditition.MartinVon einem Smartphone gedendet.
null

Peter Relson

unread,
Mar 20, 2020, 8:42:14 AM3/20/20
to ASSEMBL...@listserv.uga.edu
<snip>
But only TARGET1 generates an IEW2456E "unresolved symbol" error message,
and that much I understand.
</snip>

You would not get an unresolved symbol error message for an unresolved
WXTRN.
As others noted, you got the error message because TARGET1 was not
resolved and was not (uniformly) weak.

Peter Relson
z/OS Core Technology Design

David Eisenberg

unread,
Mar 20, 2020, 12:38:43 PM3/20/20
to ASSEMBL...@listserv.uga.edu
Thanks for the replies, everyone; I appreciate the help.

Just to clarify, I do understand why (in my example) the binder produces an "unresolved symbol" error *only* for TARGET1 and not for TARGET2. It's just the Cross-Reference table that puzzled me. I had assumed that because MODULEB declares TARGET1 as weak, that its corresponding Cross-Reference table entry would say $UNRESOLVED(W) ; i.e., weak.

But if I understand all the replies correctly, the binder has determined that TARGET1 is an unresolved strong reference *somewhere*, and as a result, the Cross-Reference reports TARGET1 as an unresolved strong reference *everywhere* that it is found.

This further implies that the only time I would see $UNRESOLVED(W) in a Cross-Reference table is when *every* reference to that particular symbol is weak.

I hope I've got it now; if not, please feel free to try beating it into my head again (if you're so inclined!).

Thanks,

David

Charles Mills

unread,
Mar 20, 2020, 1:16:13 PM3/20/20
to ASSEMBL...@listserv.uga.edu
I think you've got it!

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of David Eisenberg
Reply all
Reply to author
Forward
0 new messages