blank csects

[Paul Edwards]

(thanks for the replies to the other message - i found the

documentation based on that and will try it in due course)

A separate question - I use blank (unnamed) csects normally,

and the linker I use (pdld) handles them fine (as does IEWL),

if they were assembled with ifox (assembler xf).

But pdld couldn't handle the object code from z390 asm

(and had to be updated to cater for the difference).

The pdld author made this comment:

I compared the one.obj and two.obj with mvsstart.obj and it seems to be as you said that "$PRIVATE" SD symbols produced by z390 have the same meaning as MVS-produced PC symbols (so both are section symbols with the same meaning). I am not sure it is a bug but it might be good to ask what is the reasoning behind doing it this way instead of just using PC symbols.

I attached updated mainframe.c with support for "$PRIVATE" SD symbols added.

Any comments?

(not claiming I personally understand what he's talking about)

Thanks. Paul.

[Abe Kornelis]

I'm sorry I do understand the question but have no answer. You'd have to ask the original author of z390: Don Higgins

--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/z390/c98bd9fc-fd9d-4287-b367-b2f1c1347a6en%40googlegroups.com.

[Paul Edwards]

Ok, another issue is that the z390 linker itself can't handle the

blank CSECTs (IBM's linker can).

05:43:01 one       LZ390 START USING z390 1.8.3 ON J2SE 1.8.0_461 08/17/25
LZ390W warning - ignoring duplicate CSECT - $PRIVATE
05:43:01 one       LZ390 ENDED   RC= 0 SEC= 0 MEM(MB)= 13 IO=66

That produces a valid executable, but it doesn't run as expected -

it seems that the first unnamed CSECT is replaced by the last.

BFN. Paul.

[Jon Perryman]

I don't understand how you aren't getting unresolved externals. You say "largest csect wins" but "wins" is meaningless to me. Let's assume you have 3 unnamed csects and one of them wins. I assume you are saying the 2 losers are dropped but somehow you don't get "unresolved references" from their "unique extrns" being dropped. Alternatively, the 2 losers are retained but lost something and I'm guessing they somehow lost their "unique extern" (not defined in the winner) to the winner but somehow the winner stole the "unique extrn" from the loser. What am I misunderstanding?

>  The behavior of z390 below - having $PRIVATE behave the
> same as other CSECTs on MVS - ie, the largest csect wins
> (actually, z390 is a bit different - the last wins) differs from
> MVS. On MVS, $PRIVATE is special - they are all used,
> instead of having the largest win

[Jon Perryman]

Of course there aren't any unresolved externals because this program does not reference any externals. What makes this a winner and is it different from a loser? Does the loser also have ENTRY TWO? Does the calling program use V(TWO) and the entry of the loser program.

On Sun, Aug 17, 2025 at 6:16 PM Paul Edwards <muta...@gmail.com> wrote:

The winner looks like this:

         AMODE 64
         RMODE 64
         CSECT
         YREGS
*
         ENTRY TWO
TWO      DS    0H
         USING TWO,R15
         LA    R15,3
         BR    R14
         END


No unresolved externals.

A valid program in its own right. Even though it was
designed to be a subroutine.

BFN. Paul.

[Joe Monk]

Here's what the book says about multiple unnamed CSECTs...

"If symbol is not specified, or if it is a sequence symbol, the CSECT instruction initiates, or indicates the continuation of the unnamed control section."

"The ENTRY instruction identifies symbols defined in this source module as “external” so that they can be referred to by another source module. These symbols are entry symbols."

https://www.ibm.com/docs/en/hla-and-tf/1.6.0?topic=statements-csect-instruction

Joe

--

You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/z390/CAByJhJkSS-hdgq3URi3nPWA5iiaGfjHmo_uP14urC-z6wVoYdw%40mail.gmail.com.

[Paul Edwards]

I'm not sure if you're making a point. I just explained what
was happening, technically. That was my original "problem
report". It behaves differently from IBM. If that's a design
choice, so be it - I can now use pdld instead and not have
that problem.

Regardless, here is the loser:

AMODE 64
RMODE 64
CSECT
YREGS
*

ENTRY ONE
ONE DS 0H
SAVE (14,12),,ONE
LGR R10,R15
USING ONE,R10
LGR R9,R13
LA R13,SAVEAREA
WTO 'About to call two for two'
LG R15,=VD(TWO)
LGR R0,R14
BALR R14,R15
LGR R14,R0
LGR R13,R9
RETURN (14,12),RC=(15)
SAVEAREA DS 19F
END

[Paul Edwards]

First of all - apologies - I said something a bit misleading.
This is hand-generated assembler, in the same STYLE
that gccmvs-generated code is in.

Regardless - yes, I used externs. And you can't have duplicate
externs - you get an error - that's exactly what I want. Instead
of a clean link (in this case with a warning), I get a hard error
with duplicate externs.

If I have a function verylongOne and verylongTwo, both
will be truncated by gccmvs to VERYLONG and if I use
externs instead of named csects, I get notified of the clash.

The behavior of z390 below - having $PRIVATE behave the
same as other CSECTs on MVS - ie, the largest csect wins
(actually, z390 is a bit different - the last wins) differs from
MVS. On MVS, $PRIVATE is special - they are all used,

instead of having the largest win.

BFN. Paul.




On Mon, Aug 18, 2025 at 8:09 AM Jon Perryman <jon.pe...@gmail.com> wrote:
>
> I asked because you say you have multiple unnamed csects that link without a problem but won't run correctly. Since you can't access the unnamed csects directly, I assume you're using EXTRNs, possibly WXTRNs. Since you can't generate unique csect names, how are you generating unique EXTRNs? I'm guessing they are not unique and the wrong EXTRN is being called. The link output should show references. You could insert WTO in each csect that identifies when it is called. In other words, I think you have 3 unnamed csects with EXTERN AAA and 3 V(AAA) that all reference the first EXTRN and ignore the other 2.
>
> On Sun, Aug 17, 2025 at 4:36 PM Paul Edwards <muta...@gmail.com> wrote:
>>
>> The code in question will be generated by the C compiler (gccmvs).
>>
>> Even IBM C doesn't have the ability to automatically name CSECTs.
>>
>> Note that if I changed gccmvs to attempt to automatically create
>> a CSECT name based on some factor like the function name,
>> then if there is a name clash, I am not alerted to that fact. Instead,
>> the biggest CSECT silently takes effect. A terrible situation.
>>
>> I consider THAT to be the bad practice.
>>
>> YMMV and I'm not asking you to stop naming CSECTs. :-)
>>
>> BFN. Paul.
>>
>>
>>
>>
>> On Mon, Aug 18, 2025 at 7:29 AM Jon Perryman <jon.pe...@gmail.com> wrote:
>> >
>> > Paul, do you have a real need for not naming csects? This is a bad practice.

>> >> To view this discussion visit https://groups.google.com/d/msgid/z390/8302728e-4f91-4387-8be0-ed37b78d6969n%40googlegroups.com.

[Jon Perryman]

Paul, do you have a real need for not naming csects? This is a bad practice.

On Sat, Aug 16, 2025 at 3:24 PM Paul Edwards <muta...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/z390/8302728e-4f91-4387-8be0-ed37b78d6969n%40googlegroups.com.

[Paul Edwards]

The code in question will be generated by the C compiler (gccmvs).

Even IBM C doesn't have the ability to automatically name CSECTs.

Note that if I changed gccmvs to attempt to automatically create
a CSECT name based on some factor like the function name,
then if there is a name clash, I am not alerted to that fact. Instead,
the biggest CSECT silently takes effect. A terrible situation.

I consider THAT to be the bad practice.

YMMV and I'm not asking you to stop naming CSECTs. :-)

BFN. Paul.




On Mon, Aug 18, 2025 at 7:29 AM Jon Perryman <jon.pe...@gmail.com> wrote:
>

[Jon Perryman]

I asked because you say you have multiple unnamed csects that link without a problem but won't run correctly. Since you can't access the unnamed csects directly, I assume you're using EXTRNs, possibly WXTRNs. Since you can't generate unique csect names, how are you generating unique EXTRNs? I'm guessing they are not unique and the wrong EXTRN is being called. The link output should show references. You could insert WTO in each csect that identifies when it is called. In other words, I think you have 3 unnamed csects with EXTERN AAA and 3 V(AAA) that all reference the first EXTRN and ignore the other 2.

[Paul Edwards]

The winner looks like this:

AMODE 64
RMODE 64
CSECT
YREGS
*
ENTRY TWO
TWO DS 0H
USING TWO,R15
LA R15,3
BR R14
END


No unresolved externals.

A valid program in its own right. Even though it was
designed to be a subroutine.

BFN. Paul.

[Jon Perryman]

Hi Paul,

I was trying to help you solve your problem (not make a point). I'm still unclear what problem you are having and these questions were to have you explain it in a way  I could understand and potentially help you to look at the problem from a different perspective.

Now that you've shown TWO is the winner and ONE is the loser, I'm guessing that you're saying module TWO is executed when the load module is called instead of module ONE. If that's the case, then this problem is solved by coding an ENTRY ONE statement in the linker/binder. Alternatively, you can name the load module ONE. I don't believe IBM guarantees the sequence of modules in a load module except when ORDER statements are used.Since you don't have CSECT names,you can't use the ORDER statement.

[Jon Perryman]

Hi Paul,

This now makes sense. For the future, here are a couple suggestions to close this out.

1. Always code the link ENTRY statement because it will guarantee the load modules contains everything necessary and will ensure the load module starts at the expected program. This would have told you if ONE was excluded and fixed any module sequence errors. 

2. You think IBM keeping all CSECTs is but it has always been a bad idea because it keeps unused garbage modules causing load modules to grow over time. We have programs like SMP/e that delete these duplicates but there are some cases it fails to catch. I think many software developers would prefer the z390 method over IBM binder. 

Sorry for wasting your time but I thought you were trying to solve a problem. 

On Mon, Aug 18, 2025 at 7:36 AM Paul Edwards <muta...@gmail.com> wrote:

Hi Jon.

I have already worked around the problem for my own use,
by switching to pdld. I don't need a different workaround.

I was just reporting an issue/bug, unless the authors want
to say they deliberately want to differ from IBM's behavior.

Note that "ENTRY ONE" is unlikely to work, because ONE
does not exist any more - the entire CSECT replaced by
TWO - or at least that's what the warning says, and also
what IBM's linker does with duplicate named CSECTs
(noting that z390's linker appears to be behaving like an
IBM named csect).

[Abe Kornelis]

hi all, if you have an issue with z390 functionality or behaviour, feel free to create an issue on the repository: z390development/z390 on www.github.com.

Code to reproduce the issue is highly appreciated. 

kind regards & happy programming!

Abe.

--

You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/z390/CAByJhJnsoX%3DienSjaShz_j_Gcbe8sPJnNnsiBt3hezLeoszprg%40mail.gmail.com.

[Paul Edwards]

Hi Jon.

I have already worked around the problem for my own use,
by switching to pdld. I don't need a different workaround.

I was just reporting an issue/bug, unless the authors want
to say they deliberately want to differ from IBM's behavior.

Note that "ENTRY ONE" is unlikely to work, because ONE
does not exist any more - the entire CSECT replaced by
TWO - or at least that's what the warning says, and also
what IBM's linker does with duplicate named CSECTs
(noting that z390's linker appears to be behaving like an
IBM named csect).

BFN. Paul.

On Mon, Aug 18, 2025 at 10:23 PM Jon Perryman <jon.pe...@gmail.com> wrote:
>

[Paul Edwards]

Done:

https://github.com/z390development/z390/issues/666

An appropriate number too. :-)

I raised 664 as well. Not sure why there is no 665.

BFN. Paul.