ADATA is not "simple" but I think it is the right answer to problems of the general form "I have a DSECT in HLASM. I want to output equivalent information in another programming language."
I did exactly that. I wrote a program -- good enough to be distributed as part of a commercial product, albeit with an "as-is" disclaimer -- that processed SMF record and similar DSECTs and output equivalent information in a proprietary schema language. SMF record DSECTs are quite complex, with redefinitions and symbols defined arguably incorrectly (such as integer fields defined as XL4 or CL4). I do not own the rights to the code or I would happily share it with you. I wrote it in C++ but it could have been written in assembler. (An added complexity was that I wanted it to be able to run in a debugger in Windows, so it had to deal with both endian issues and EBCDIC-ASCII in that situation. Also RECFM=V records, which are not very Windows-friendly.) It was not a trivial project, and I did not get it all right on the first try, but it ultimately worked well, worked more or less perfectly for what it was intended to do. One interesting attribute of ADATA is that you get the complete source, so you can include any HLASM comments appropriately in your output. I started by writing an "intelligent dump" program to display the contents of an ADATA file, and then refined that until it was producing the desired output (with the dump available as a debugging option in the finished program). Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Joseph Reichman Sent: Thursday, December 30, 2021 3:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Determining a group item You think processing adata is simpler I mean they data names are not in order I could get what I want with esid and offset Doing it from the assembler was thinking of using AREAD but I am sure you know better than me Thank you > On Dec 30, 2021, at 5:41 PM, Bob Raicer <r...@raicer.com> wrote: > > I'm not clear on what you (Joseph Reichman) are attempting to > accomplish. If you are going to produce a Rexx program that does > something with symbols which appear in some form of an assembler > data structure, then you could do something like the example shown > below and (as others have suggested) subsequently process the > SYSADATA file with the Rexx program. > > > D-Loc Object Code Addr1 Addr2 Stmt Source Statement > 00000000 00000000 00000046 1 TEST DSECT , > 00000000 4040404040404040 2 X1 DC 7CL10' ' > 00000046 3 X2 DC 0CL20' ' > 00000000 00000046 4 GROUP1 EQU X1,*-X1,C'C' > 5 End , > > Symbol Cross Reference > Symbol Length Value Id Type Asm Program Defn References > GROUP1 70 00000000 FFFFFFFF C 4 > TEST 1 00000000 FFFFFFFF J 1 > X1 10 00000000 FFFFFFFF C C 2 4 > X2 20 00000046 FFFFFFFF C C 3 > > Dsect Cross Reference > Dsect Length Id Defn Con Member > TEST 00000046 FFFFFFFF 1 PRIMARY INPUT > > > Here is an extraction from the High Level Assembler Language > Reference (V1.6) regarding length attributes of symbols when the > "Duplication Factor" is zero: > > * A duplication factor of zero is permitted, except for literals, > * with the following results: > * > * - No value is assembled. > * > * - Alignment is forced according to the type of constant > * specified, if no length attribute is present. > * > * - The length attribute of the symbol naming the constant is > * established according to the implicitly or explicitly specified > * length. > > For reasons lost in antiquity, an explicitly specified Length value > must be positive, e.g., CL0' ' is invalid. > > Note that: > - The Length Attribute of symbol X1 is 10 (decimal) even though it > occupies 70 bytes. > > - The Length Attribute of symbol X2 is 20 (decimal) even though it > occupies zero bytes. > > - The GROUP1 equate gets you the origin location and proper length > of a collection of items. > > There are all kinds of quirks and inconsistencies in how the assembler > treats the length attributes of symbols. For example, the length > attribute of a DSECT (e.g., L'TEST in this coding example) is always 1 > even though the proper length is reflected in the DSECT Cross Reference.
