I’m running all of this under tso but I guess that’s irrelevant Thanks
> On Jan 1, 2022, at 8:29 PM, Charles Mills <charl...@mcn.org> wrote: > > You code the minimal valid source "program" that includes the COPY member. > Something like > > MYPROG CSECT > COPY member > END > > Then you process the SYSADATA from that assembly. > > Here is a sanitized version of my job: > > //ASSEMBLE EXEC PGM=ASMA90,COND=(12,LE),REGION=2M, > // PARM='ADATA,TERM' > //SYSLIB DD DSN=CEE.SCEEMAC,DISP=SHR LE MACROS > // DD DISP=SHR,DSN=CICSTS55.CICS.SDFHMAC CICS > // DD DSN=TCPIP.SEZANMAC,DISP=SHR > // DD DISP=SHR,DSN=SYS1.MACLIB System macros > //SYSPUNCH DD DUMMY > //SYSIN DD * > EZASMF77 > END > /* > //SYSLIN DD DUMMY > //SYSADATA DD SPACE=(TRK,(15,15)),DISP=(NEW,PASS) > //SYSPRINT DD SYSOUT=* > //SYSTERM DD SYSOUT=* > //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,2)) > //* > //* Process the ADATA > //CZADEFBL EXEC PGM=myprogram, > // PARM=(... > // ) > //SYSADATA DD DSN=*.ASSEMBLE.SYSADATA,DISP=(OLD,DELETE) > Etc. > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Joseph Reichman > Sent: Saturday, January 1, 2022 5:12 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Determining a group item > > I hear you only thing is there isn’t a sysadata file for the copybooks, they > are included in programs. The production programs have sysadata files. So I > would have to look for record X’0020’ esid records ? > > >> On Jan 1, 2022, at 7:56 PM, Charles Mills <charl...@mcn.org> wrote: >> >> 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.
