cc370 silently drops -Wl,--ac,N, and ld370 --pack drops the AC again: an unauthorized module that looks authorized

[mgrossmann]

What happens

Building an APF-authorized program with the driver produces a module with
AC(0), without a diagnostic:

cc370 -O1 -Iinclude -Lbuild/sdk -Wl,--ac,1 prog.c -o PROG -flinker-output=xmit
cc370 -O1 -Iinclude -Lbuild/sdk           prog.c -o PROG -flinker-output=xmit

The two outputs are byte-identical. -Wl,--ac,1 never reaches ld370.
(Passing --ac 1 to the driver directly is at least loud — it reaches cc1 as
-fac and errors with unrecognized command line option "-fac".)

Calling ld370 yourself does set it:

cc370 -O1 -Iinclude -c prog.c -o prog.o
ld370 --entry @@CRT0 --ac 1 -o PROG crt0.o prog.o -L<lib> -lc   # differs from the same
                                                                # link without --ac

And then --pack loses it again

ld370 --pack rebuilds the directory entries and does not carry the AC over
from the member file. It has to be repeated on the pack step, which is not
mentioned in the usage text (the --pack line lists only
-o / -xmit / -iebcopy, though --ac is accepted there and does change the
output):

ld370 --pack PROG=PROG --ac 1 -o out -xmit --dsn <LOADLIB>

Why it costs a cycle rather than a minute

An unauthorized module is indistinguishable from an authorized one until it
runs. Then the first MODESET KEY=ZERO,MODE=SUP ends the step S047 — and
with an empty SYSPRINT, because stdio buffers are lost with the unclosed DCB
on an abend, fflush() notwithstanding. So the symptom is "my program produced
no output and abended", with nothing pointing at the link step.

Found while building an authorized probe for mvslovers/libc370#58 on MVS 3.8j.
It cost two deploy cycles: the first because the driver dropped the flag, the
second because --pack dropped it again after ld370 had set it.

A working check once it runs: an authorized program's WTO appears in the job
log without the + prefix that marks a problem-program message.

Suggested

Any of these would have saved the cycles, roughly in order of cost:

1. ld370 --pack carries the AC (and RENT/REUS) over from the packed member
   rather than defaulting them — the member file already knows what it is.
2. The driver passes -Wl, options through to ld370, or at minimum
   rejects the ones it drops instead of ignoring them silently.
3. Document --ac on the --pack usage line.

Adjacent observation, not necessarily a bug

ld370 --norent produces a byte-identical module to the default link. If
RENT is off by default that is correct and only surprising; if it is on, the
flag is being ignored the way -Wl,--ac is. Worth a look while in this code —
I could not tell from the outside which of the two it is.