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.
