Re: Determining a group item
Charles
I can subscript the setc symbol from the AREAD
I’m doing this in a call from the rexx
As long as I get the production copybook
Once this is done it’s done
Meaning I don’t have to change it every time the copybook(s) change
I am not really aware when those change take place and if they do I would have
to assemble a new sysadata file. As far as the Duplication factor
It always been 0 or nothing if it’s zero won’t bump it up
If not I can doSETA L’FIELDA
And bump up the value by that
I really don’t know when the copybooks are changed mostly in the beginning of
year but not necessarily
Every time that happens I would have to reassemble to produce an adata of the
copybook(‘s)
It maybe easier with adata but necessarily more practical
Thanks
> On Jan 2, 2022, at 7:30 PM, Charles Mills wrote:
>
> 1. Unless my recollection of AREAD is flawed, it will just give you the raw
> source code. It's not much different from reading the source file. In order
> to determine offsets and so forth you would have to write your own assembler:
> you will have to "know" what FOO DS 3PL8 "means." You will have to bump your
> internal location counter by 24 and read the next card image. You will have
> to understand the location counter implication of DS 0F and ORG FOO-7.
>
> 2. With regard to processing the listing rather than the ADATA, I have to say
> that "intellectually" I don't like it ("listings are for people; ADATA is for
> this sort of task") but practically it sounds like a fine idea. All of the
> offsets and symbol values are there and it is easy to figure out -- no trying
> to interpret some structure of binary data.
>
> (Is it clear whether a symbol is relocatable or not? Is the difference
> between FOO EQU * versus FOO EQU 126 clear from the listing?)
>
> 3. You might consider Rexx for the processing language, especially if you are
> going to process SYSPRINT.
>
> 4. Whichever route you go, I would divide the project up into two phases:
>
> i. Parse the input (SYSPRINT or ADATA). Build a big table with everything you
> think you might need to know about each symbol (name, offset, value, format,
> length, comment). Dump that table out to make sure it is right and you
> understand what you have done.
>
> ii. Turn it into the Rexx statements that you need.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Joseph Reichman
> Sent: Sunday, January 2, 2022 1:31 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Determining a group item
>
> That’s what I thought not punching out but doing a number of SETC to generate
> dc’s
> That will help me define/populate Rexx variables
>
> Thanks
>
>> On Jan 2, 2022, at 4:27 PM, Steve Smith wrote:
>>
>> When I've done similar things, I just wrote a macro to replace DS, and it
>> punched out the appropriate line in whatever language I needed. Seemed to
>> be far easier than reprocessing source/listings/adata.
>>
>> sas
Re: Determining a group item
1. Unless my recollection of AREAD is flawed, it will just give you the raw
source code. It's not much different from reading the source file. In order to
determine offsets and so forth you would have to write your own assembler: you
will have to "know" what FOO DS 3PL8 "means." You will have to bump your
internal location counter by 24 and read the next card image. You will have to
understand the location counter implication of DS 0F and ORG FOO-7.
2. With regard to processing the listing rather than the ADATA, I have to say
that "intellectually" I don't like it ("listings are for people; ADATA is for
this sort of task") but practically it sounds like a fine idea. All of the
offsets and symbol values are there and it is easy to figure out -- no trying
to interpret some structure of binary data.
(Is it clear whether a symbol is relocatable or not? Is the difference between
FOO EQU * versus FOO EQU 126 clear from the listing?)
3. You might consider Rexx for the processing language, especially if you are
going to process SYSPRINT.
4. Whichever route you go, I would divide the project up into two phases:
i. Parse the input (SYSPRINT or ADATA). Build a big table with everything you
think you might need to know about each symbol (name, offset, value, format,
length, comment). Dump that table out to make sure it is right and you
understand what you have done.
ii. Turn it into the Rexx statements that you need.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Joseph Reichman
Sent: Sunday, January 2, 2022 1:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Determining a group item
That’s what I thought not punching out but doing a number of SETC to generate
dc’s
That will help me define/populate Rexx variables
Thanks
> On Jan 2, 2022, at 4:27 PM, Steve Smith wrote:
>
> When I've done similar things, I just wrote a macro to replace DS, and it
> punched out the appropriate line in whatever language I needed. Seemed to
> be far easier than reprocessing source/listings/adata.
>
> sas
Re: ADATA dump utility [was: RE: Determining a group item]
Sorry. Don't own one line of the code. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Sunday, January 2, 2022 12:31 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: ADATA dump utility [was: RE: Determining a group item] Charles, Would it be possible for you to contribute only the "intelligent ADATA dump" code to CBT, without any of your firm's IP included? That seems to be a notably generic utility that would be a wonderful contribution to the IBM programming community. Converting such code to other languages (MetalC, HLASM, python, etc.) would then be an exercise for the rest of the community to take up. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Saturday, January 1, 2022 7:56 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Determining a group item 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Determining a group item
That’s what I thought not punching out but doing a number of SETC to generate dc’s That will help me define/populate Rexx variables Thanks > On Jan 2, 2022, at 4:27 PM, Steve Smith wrote: > > When I've done similar things, I just wrote a macro to replace DS, and it > punched out the appropriate line in whatever language I needed. Seemed to > be far easier than reprocessing source/listings/adata. > > sas
Re: Determining a group item
When I've done similar things, I just wrote a macro to replace DS, and it punched out the appropriate line in whatever language I needed. Seemed to be far easier than reprocessing source/listings/adata. sas
Re: ADATA dump utility [was: RE: Determining a group item]
I can't really see what you want. ADATA is fairly dense, but it's much easier to process than SMF data. All the record layouts have good DSECTs available. Just do it. sas On Sun, Jan 2, 2022 at 3:31 PM Farley, Peter x23353 < 0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote: > Charles, > > Would it be possible for you to contribute only the "intelligent ADATA > dump" code to CBT, without any of your firm's IP included? That seems to > be a notably generic utility that would be a wonderful contribution to the > IBM programming community. > > Converting such code to other languages (MetalC, HLASM, python, etc.) > would then be an exercise for the rest of the community to take up. > > Peter > >
ADATA dump utility [was: RE: Determining a group item]
Charles, Would it be possible for you to contribute only the "intelligent ADATA dump" code to CBT, without any of your firm's IP included? That seems to be a notably generic utility that would be a wonderful contribution to the IBM programming community. Converting such code to other languages (MetalC, HLASM, python, etc.) would then be an exercise for the rest of the community to take up. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Saturday, January 1, 2022 7:56 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Determining a group item 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Determining a group item
> On Jan 2, 2022, at 08:48:38, Martin Trübne wrote: > >>> Does it grok SYSIN and SYSLIB in z/FS files? > > >>> For the record: My HLASM debugger eats source code to support >>> source-debugging. > > To make this a little clearer: It absorbs source-listings whichever way the > HLASM produces it. > Ah, I misunderstood that you depended on accessing the SYSIN and SYSLIB as reported in the Data Set Summary rather than only the SYSPRINT Thanks, gil
Re: Determining a group item
Paul, your wrote: Does it grok SYSIN and SYSLIB in z/FS files? Which I do not understand (english is not my native language- HLASM is much better) Since you cited a line from my posting For the record: My HLASM debugger eats source code to support source-debugging. To make this a little clearer: It absorbs source-listings whichever way the HLASM produces it. for VSE I read the spoolfiles, for MVS I expect the listing of the compile in a VSAM file--- If you have any other repo for the listings, it is no big deal to adapt the exit that does the reading. Does that help steering into the right direction? Martin
Re: Determining a group item
My initial thoughts were having the copybook preceded my AREAD Bottom line with AREAD I get the entire 80 byte assembler sysin Many have said I can’t do this way I may give it a try I need to generate 4 fields for rexx 1) address of the name 2) length of the name 3) address of the value 4) length of the value > On Jan 2, 2022, at 8:16 AM, Paul Gilmartin > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > On Jan 2, 2022, at 01:15:38, Martin Trübner wrote: >>... >> For the record: My HLASM debugger eats source code to support >> source-debugging. >> > Does it grok SYSIN and SYSLIB in z/FS files? > > -- gil
Re: Determining a group item
On Jan 2, 2022, at 01:15:38, Martin Trübner wrote: > ... > For the record: My HLASM debugger eats source code to support > source-debugging. > Does it grok SYSIN and SYSLIB in z/FS files? -- gil
Re: Determining a group item
Joseph, how about using the output of a HLASM run to determine what you need? It is not as exact as ADATA but you get there for 100 % For the record: My HLASM debugger eats source code to support source-debugging. The first version (the one I am still proud of) did it against the compile listings. Meanwhile I wrote code to diggest ADATA stuff as alternative. To determine the DSECT (or CSECT) used in a given instruction is 100% correct with the ADATA files- but that is rarely needed. Other cases are equal. From the development point using compiler-listings is certainly easier. Martin
