Shmuel (Seymour J.) Metz writes: > One other ambiguity is that although the DSECT generated by the ASMADATA > macro begins with the RDW, the offsets are against the byte following the > RDW.
That seems to be true, and I'm very sorry that my initial post on this (written in a hurry while on leave) was incorrect. Thanks for pointing this out. It's a long time since I did any ADATA processing myself, and I wasn't sure about "start of record", so I had a quick look at the code to build ADATA records, in particular filtering for lines containing the word "offset" in the comments. I saw a consistent pattern of statements that subtract the address of ASMADATA (which is the start of the RDW) from the address of the field to calculate the offset. However, I failed to spot that a line of code had been inserted later in each case which then subtracts 4 from the offset to allow for the RDW length. Looking into that more deeply, I found that this change was made for APAR PQ89655 in 2004 where a decision was made to change the offsets to exclude the RDW. So the original code, comments and documentation assumed that the offset included the RDW, but APAR PQ89655 reduced this offset by 4 to exclude the RDW. No wonder there has been confusion! Just to be sure, I've also checked some ADATA files to verify that the offset is indeed from after the RDW. I have made a note to get the documentation updated to clarify that the offset is relative to the start of the data record (that is, the common header), not the RDW. Jonathan Scott, HLASM IBM Hursley, UK
