Feature request: add "(BIND on <date> <time> V03 M08)" section to load modules to allow ISPF to show CHANGED date

[meltdown03]

Here is a screenshot of load modules, with some having a "CHANGED" date and the new ones, compiled with cc370, do not:

Here is inside the module, assuming it's the Metadata that ISPF/RFE uses to show that:

[meltdown03]

Here is JCL of a job that can get all that info:

//AMBLIST JOB CLASS=A,MSGCLASS=H,NOTIFY=&SYSUID
//STEP1    EXEC PGM=AMBLIST
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DISP=SHR,DSN=HTTPD.LINKLIB
//SYSIN    DD *
  LISTIDR  DDN=SYSUT1,MEMBER=HTTPD
/*

It returns that the IDR information is incomplete on the new cc370-created load modules

[mgrossmann]

This landed in PR #46 (e7b7588, 2026-08-13). Every module ld370 links now carries a linkage-editor IDR after the SPZAP record:

80 15 82  D3C4F3F7F0 4040404040  01 00  26 24 2F  01 62 51 7F
   |      "LD370"                V01 M00  2026.242   16:25:17
   +-- IDR, len-1, LKED|LASTIDR

file370 -v on a module linked today shows both records (IDR 251 bytes, IDR 22 bytes). LDDATE=YYDDD / LDTIME=HHMMSS override the host clock for reproducible builds.

What still differs from a genuine IEWL module

Measured against the IEWL reference member kept as an oracle in ld370/tests/fixtures/e2e.iewl-member.bin:

record	IEWL	ld370 today
SPZAP IDR, 251 B	present	present
linkage-editor IDR, 22 B	5752SC104 V03 M08	LD370 V01 M00
translator IDR, 21 B	5741SC103 + date	absent

The product string is deliberate. This linkage editor is not 5752-SC104 and should not claim to be, so LISTIDR will name LD370 where the IBM component id would stand.

The translator IDR is the real remainder, and it is very likely the "IDR information is incomplete" your AMBLIST job reported. It carries the assembler's identification, not the linkage editor's. The data already exists: as370 writes ASM370, version 0100 and the assembly date into the END card of every object deck it produces (cols 34+). What is missing is the propagation — ld370.c:6 states it plainly: "translator IDRs are not emitted". So it is one read of the END card and one 21-byte record, not a new mechanism.

Closing

Closing this as done for what it asked: the BIND date and time are in the module, and the CHANGED column has something to read. Two invitations rather than assumptions —

• if AMBLIST LISTIDR against a module built with the current toolchain still shows something missing beyond the translator entry, please reopen with that listing;
• if the translator IDR itself is wanted, it deserves its own issue; the mechanism above is the whole of it.