Re: Determining a group item

[Joseph Reichman]

I want to use the AREAD past experience has thought me all of you know better



> On Jan 3, 2022, at 2:47 PM, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
> On Jan 3, 2022, at 12:06:53, Joseph Reichman wrote:
>> 
>> I’m just trying to generate the 4 fields need 
>> To define a variable to Rexx when using assembler 
>> 1) length of fetch value 
>> 2) address of the name of the variable 
>> 3) length of variable name 
>> 4) address of the fetch buffer
>> 
> "name"?  I see too many indirections.  What facility needs the length
> or address of the name?  IRXEXCOM and ADDRESS LINKMVS surely don't.
> 
>> I 100 % agree with Charles that using the adata is better
>> It’s just not practical 
>> 
> Alas, if what both you and Peter say are true, no scheme mentioned
> so far is both practical and correct.  Take your pick.
> 
>> I would have to be aware every time one of these copybooks changes 
>> re-assemble it to get adata 
>> Nobody is going to tell me so 
>> Everyday I would have to check endeavor to see if they copybooks were 
>> changed 
>> Or else I would have to read production programs that use the copybooks 
>> 
> Isn't that equally so for the AREAD scheme?  Or do you plan to read
> the copybooks dynamically?  You might as well invoke HLASM dynamically.
> 
> Concerning length of this thread: 
> .
> 
> -- gil

Re: Determining a group item

[Paul Gilmartin]

On Jan 3, 2022, at 12:35:15, Joseph Reichman wrote:
> 
> Aware of what 
> ...
>> On Jan 3, 2022, at 2:30 PM, Seymour J Metz wrote:
>> 
>> You have to be aware regardless.
>> 
>> 
>> From: Joseph Reichman
>> Sent: Monday, January 3, 2022 2:06 PM
>> ...
>> I would have to be aware every time one of these copybooks changes 
>> re-assemble it to get adata
>>  
Ah, the drawback of top-posting.  I posted a similar remark, but proximate
To Joseph's "aware" for clarity.

"Regardless", whether copybook or ADATA is used, it must match the time of
The assembly.  To ensure this you  must take a snapshot of the copybook or
ADATA or generated Rexx at the time of assembly, and preserve an audit trail.

-- gil

Re: Determining a group item

[Paul Gilmartin]

On Jan 3, 2022, at 12:06:53, Joseph Reichman wrote:
> 
> I’m just trying to generate the 4 fields need 
> To define a variable to Rexx when using assembler 
> 1) length of fetch value 
> 2) address of the name of the variable 
> 3) length of variable name 
> 4) address of the fetch buffer
>  
"name"?  I see too many indirections.  What facility needs the length
or address of the name?  IRXEXCOM and ADDRESS LINKMVS surely don't.

> I 100 % agree with Charles that using the adata is better
> It’s just not practical 
>  
Alas, if what both you and Peter say are true, no scheme mentioned
so far is both practical and correct.  Take your pick.

> I would have to be aware every time one of these copybooks changes 
> re-assemble it to get adata 
> Nobody is going to tell me so 
> Everyday I would have to check endeavor to see if they copybooks were changed 
> Or else I would have to read production programs that use the copybooks 
>  
Isn't that equally so for the AREAD scheme?  Or do you plan to read
the copybooks dynamically?  You might as well invoke HLASM dynamically.

Concerning length of this thread: 
.

-- gil

Re: Determining a group item

[Joseph Reichman]

Aware of what 

When something goes wrong or gets updated 

You probably were a CTO 

I’m just a peon 



> On Jan 3, 2022, at 2:30 PM, Seymour J Metz  wrote:
> 
> You have to be aware regardless.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on 
> behalf of Joseph Reichman [reichman...@gmail.com]
> Sent: Monday, January 3, 2022 2:06 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Determining a group item
> 
> I’m just trying to generate the 4 fields need
> To define a variable to Rexx when using assembler
> 1) length of fetch value
> 2) address of the name of the variable
> 3) length of variable name
> 4) address of the fetch buffer
> 
> I 100 % agree with Charles that using the adata is better
> 
> It’s just not practical
> 
> I would have to be aware every time one of these copybooks changes 
> re-assemble it to get adata
> 
> Nobody is going to tell me so
> 
> Everyday I would have to check endeavor to see if they copybooks were changed
> 
> Or else I would have to read production programs that use the copybooks
> 
>> On Jan 3, 2022, at 1:06 PM, Charles Mills  wrote:
>> 
>> Well, could be. I am not always totally adept at deducing Joseph's 
>> requirements.
>> 
>> In any event what you suggest would be a great way of doing things.
>> 
>> I read what Joseph writes below as saying he wants something like
>> 
>> LASTNAME_Address = 1
>> LASTNAME_Length = 16
>> 
>> Not sure what he means by address (offset?) and length of name as opposed to 
>> address and length of value.
>> 
>> Charles
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
>> On Behalf Of Martin Trübner
>> Sent: Monday, January 3, 2022 9:05 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: Determining a group item
>> 
>> Charles,
>> 
>> 
>> the way I understand Joseph is that he wants
>> 
>>  CALL POPULATE_A_RECORD
>> 
>> and then have variables LASTNAME FRSTNAME ZIPCODE and BIRTHYR populates
>> with valid data.
>> 
>> 
>> Best
>> 
>> 
>> Martin
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
>> On Behalf Of Joseph Reichman
>> Sent: Sunday, January 2, 2022 7:07 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: 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
>> 
>> The DCDS record has all the information you need. Should be no big deal
>> to code the ADEXIT to spit out information that can then be used by a
>> REXX program to populate the variables.
>> 
>> I can only guess for a stand-alone program- but there is no big difference.
>> 
>> 
>> Martin
>> 
>> 
>> 
 Am 03.01.22 um 15:50 schrieb Charles Mills:
>>> There is an OOP concept called an accessor or getter. I am not finding a 
>>> succinct definition on the Web but perhaps you can.
>>> 
>>> Anyway, as an alternative to generating the four fields you describe below, 
>>> you might consider generating accessor routines. (This is on the output 
>>> side of things and independent of AREAD, ADATA or SYSPRINT input.)
>>> 
>>> Assume the following is the record to be accessed from Rexx:
>>> 
>>> CLIENT   DSECT
>>> LASTNAME DSCL16
>>> FRSTNAME DSCL12
>>> ZIPCODE  DSF
>>> BIRTHYR  DSH
>>> 
>>> The program would return the following Rexx code (untested):
>>> 
>>> LASTNAME_Get: Return SubStr(Arg(1), 1, 16)
>>> FRSTNAME_Get: Return SubStr(Arg(1), 17, 12)
>>> ZIPCODE_Get: Return C2D(SubStr(Arg(1), 29, 4))
>>> BIRTHYR_Get: Return C2D(SubStr(Arg(1), 33, 2))
>>> 
>>> Now your Rexx application programmer could code lines like the following 
>>> (assuming CLIENT_Rec contained a CLIENT record):
>>> 
>>> Say "Client" LASTNAME_Get(CLIENT_Rec) "was born in" BIRTHYR_Get(CLIENT_Rec)
>>> 
>>> Charles
>>> 

Re: Determining a group item

[Seymour J Metz]

You have to be aware regardless.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Joseph Reichman [reichman...@gmail.com]
Sent: Monday, January 3, 2022 2:06 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Determining a group item

I’m just trying to generate the 4 fields need
To define a variable to Rexx when using assembler
1) length of fetch value
2) address of the name of the variable
 3) length of variable name
4) address of the fetch buffer

I 100 % agree with Charles that using the adata is better

It’s just not practical

I would have to be aware every time one of these copybooks changes re-assemble 
it to get adata

Nobody is going to tell me so

Everyday I would have to check endeavor to see if they copybooks were changed

Or else I would have to read production programs that use the copybooks

> On Jan 3, 2022, at 1:06 PM, Charles Mills  wrote:
>
> Well, could be. I am not always totally adept at deducing Joseph's 
> requirements.
>
> In any event what you suggest would be a great way of doing things.
>
> I read what Joseph writes below as saying he wants something like
>
> LASTNAME_Address = 1
> LASTNAME_Length = 16
>
> Not sure what he means by address (offset?) and length of name as opposed to 
> address and length of value.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Martin Trübner
> Sent: Monday, January 3, 2022 9:05 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Determining a group item
>
> Charles,
>
>
> the way I understand Joseph is that he wants
>
>   CALL POPULATE_A_RECORD
>
> and then have variables LASTNAME FRSTNAME ZIPCODE and BIRTHYR populates
> with valid data.
>
>
> Best
>
>
> Martin
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Sunday, January 2, 2022 7:07 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: 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
>
> The DCDS record has all the information you need. Should be no big deal
> to code the ADEXIT to spit out information that can then be used by a
> REXX program to populate the variables.
>
> I can only guess for a stand-alone program- but there is no big difference.
>
>
> Martin
>
>
>
>> Am 03.01.22 um 15:50 schrieb Charles Mills:
>> There is an OOP concept called an accessor or getter. I am not finding a 
>> succinct definition on the Web but perhaps you can.
>>
>> Anyway, as an alternative to generating the four fields you describe below, 
>> you might consider generating accessor routines. (This is on the output side 
>> of things and independent of AREAD, ADATA or SYSPRINT input.)
>>
>> Assume the following is the record to be accessed from Rexx:
>>
>> CLIENT   DSECT
>> LASTNAME DSCL16
>> FRSTNAME DSCL12
>> ZIPCODE  DSF
>> BIRTHYR  DSH
>>
>> The program would return the following Rexx code (untested):
>>
>> LASTNAME_Get: Return SubStr(Arg(1), 1, 16)
>> FRSTNAME_Get: Return SubStr(Arg(1), 17, 12)
>> ZIPCODE_Get: Return C2D(SubStr(Arg(1), 29, 4))
>> BIRTHYR_Get: Return C2D(SubStr(Arg(1), 33, 2))
>>
>> Now your Rexx application programmer could code lines like the following 
>> (assuming CLIENT_Rec contained a CLIENT record):
>>
>> Say "Client" LASTNAME_Get(CLIENT_Rec) "was born in" BIRTHYR_Get(CLIENT_Rec)
>>
>> Charles
>>

Re: Determining a group item

[Joseph Reichman]

I’m just trying to generate the 4 fields need 
To define a variable to Rexx when using assembler 
1) length of fetch value 
2) address of the name of the variable 
 3) length of variable name 
4) address of the fetch buffer

I 100 % agree with Charles that using the adata is better

It’s just not practical 

I would have to be aware every time one of these copybooks changes re-assemble 
it to get adata 

Nobody is going to tell me so 

Everyday I would have to check endeavor to see if they copybooks were changed 

Or else I would have to read production programs that use the copybooks 

> On Jan 3, 2022, at 1:06 PM, Charles Mills  wrote:
> 
> Well, could be. I am not always totally adept at deducing Joseph's 
> requirements.
> 
> In any event what you suggest would be a great way of doing things.
> 
> I read what Joseph writes below as saying he wants something like
> 
> LASTNAME_Address = 1
> LASTNAME_Length = 16
> 
> Not sure what he means by address (offset?) and length of name as opposed to 
> address and length of value.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Martin Trübner
> Sent: Monday, January 3, 2022 9:05 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Determining a group item
> 
> Charles,
> 
> 
> the way I understand Joseph is that he wants
> 
>   CALL POPULATE_A_RECORD
> 
> and then have variables LASTNAME FRSTNAME ZIPCODE and BIRTHYR populates 
> with valid data.
> 
> 
> Best
> 
> 
> Martin
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Sunday, January 2, 2022 7:07 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: 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
> 
> The DCDS record has all the information you need. Should be no big deal 
> to code the ADEXIT to spit out information that can then be used by a 
> REXX program to populate the variables.
> 
> I can only guess for a stand-alone program- but there is no big difference.
> 
> 
> Martin
> 
> 
> 
>> Am 03.01.22 um 15:50 schrieb Charles Mills:
>> There is an OOP concept called an accessor or getter. I am not finding a 
>> succinct definition on the Web but perhaps you can.
>> 
>> Anyway, as an alternative to generating the four fields you describe below, 
>> you might consider generating accessor routines. (This is on the output side 
>> of things and independent of AREAD, ADATA or SYSPRINT input.)
>> 
>> Assume the following is the record to be accessed from Rexx:
>> 
>> CLIENT   DSECT
>> LASTNAME DSCL16
>> FRSTNAME DSCL12
>> ZIPCODE  DSF
>> BIRTHYR  DSH
>> 
>> The program would return the following Rexx code (untested):
>> 
>> LASTNAME_Get: Return SubStr(Arg(1), 1, 16)
>> FRSTNAME_Get: Return SubStr(Arg(1), 17, 12)
>> ZIPCODE_Get: Return C2D(SubStr(Arg(1), 29, 4))
>> BIRTHYR_Get: Return C2D(SubStr(Arg(1), 33, 2))
>> 
>> Now your Rexx application programmer could code lines like the following 
>> (assuming CLIENT_Rec contained a CLIENT record):
>> 
>> Say "Client" LASTNAME_Get(CLIENT_Rec) "was born in" BIRTHYR_Get(CLIENT_Rec)
>> 
>> Charles
>> 

Re: ADATA dump utility [was: RE: Determining a group item]

[Charles Mills]

"My firm" (and it was only a little bit mine) no longer exists. All of its IP 
was acquired by a large software company often referred to with three letters, 
under an agreement that is 189 pages long and was crafted by not one, not two, 
but three! legal teams. (Our firm, their inside team, their outside firm.) I 
may actually be in violation of the NDA for saying what I just said. Really.

Trust me: it was all worth it. I LOVED the work, and I did not mind the 
transaction.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Farley, Peter x23353
Sent: Monday, January 3, 2022 9:01 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ADATA dump utility [was: RE: Determining a group item]

Understood, and thanks for the reply.

Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Charles Mills
Sent: Sunday, January 2, 2022 7:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 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

[Charles Mills]

Well, could be. I am not always totally adept at deducing Joseph's requirements.

In any event what you suggest would be a great way of doing things.

I read what Joseph writes below as saying he wants something like

LASTNAME_Address = 1
LASTNAME_Length = 16

Not sure what he means by address (offset?) and length of name as opposed to 
address and length of value.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Martin Trübner
Sent: Monday, January 3, 2022 9:05 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Determining a group item

Charles,


the way I understand Joseph is that he wants

   CALL POPULATE_A_RECORD

and then have variables LASTNAME FRSTNAME ZIPCODE and BIRTHYR populates 
with valid data.


Best


Martin

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Joseph Reichman
Sent: Sunday, January 2, 2022 7:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 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

The DCDS record has all the information you need. Should be no big deal 
to code the ADEXIT to spit out information that can then be used by a 
REXX program to populate the variables.

I can only guess for a stand-alone program- but there is no big difference.


Martin



Am 03.01.22 um 15:50 schrieb Charles Mills:
> There is an OOP concept called an accessor or getter. I am not finding a 
> succinct definition on the Web but perhaps you can.
>
> Anyway, as an alternative to generating the four fields you describe below, 
> you might consider generating accessor routines. (This is on the output side 
> of things and independent of AREAD, ADATA or SYSPRINT input.)
>
> Assume the following is the record to be accessed from Rexx:
>
> CLIENT   DSECT
> LASTNAME DSCL16
> FRSTNAME DSCL12
> ZIPCODE  DSF
> BIRTHYR  DSH
>
> The program would return the following Rexx code (untested):
>
> LASTNAME_Get: Return SubStr(Arg(1), 1, 16)
> FRSTNAME_Get: Return SubStr(Arg(1), 17, 12)
> ZIPCODE_Get: Return C2D(SubStr(Arg(1), 29, 4))
> BIRTHYR_Get: Return C2D(SubStr(Arg(1), 33, 2))
>
> Now your Rexx application programmer could code lines like the following 
> (assuming CLIENT_Rec contained a CLIENT record):
>
> Say "Client" LASTNAME_Get(CLIENT_Rec) "was born in" BIRTHYR_Get(CLIENT_Rec)
>
> Charles
>

Re: Determining a group item

[Martin Trübner]

Charles,


the way I understand Joseph is that he wants

  CALL POPULATE_A_RECORD

and then have variables LASTNAME FRSTNAME ZIPCODE and BIRTHYR populates 
with valid data.



Best


Martin

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Joseph Reichman
Sent: Sunday, January 2, 2022 7:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 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


The DCDS record has all the information you need. Should be no big deal 
to code the ADEXIT to spit out information that can then be used by a 
REXX program to populate the variables.


I can only guess for a stand-alone program- but there is no big difference.


Martin



Am 03.01.22 um 15:50 schrieb Charles Mills:

There is an OOP concept called an accessor or getter. I am not finding a 
succinct definition on the Web but perhaps you can.

Anyway, as an alternative to generating the four fields you describe below, you 
might consider generating accessor routines. (This is on the output side of 
things and independent of AREAD, ADATA or SYSPRINT input.)

Assume the following is the record to be accessed from Rexx:

CLIENT   DSECT
LASTNAME DSCL16
FRSTNAME DSCL12
ZIPCODE  DSF
BIRTHYR  DSH

The program would return the following Rexx code (untested):

LASTNAME_Get: Return SubStr(Arg(1), 1, 16)
FRSTNAME_Get: Return SubStr(Arg(1), 17, 12)
ZIPCODE_Get: Return C2D(SubStr(Arg(1), 29, 4))
BIRTHYR_Get: Return C2D(SubStr(Arg(1), 33, 2))

Now your Rexx application programmer could code lines like the following 
(assuming CLIENT_Rec contained a CLIENT record):

Say "Client" LASTNAME_Get(CLIENT_Rec) "was born in" BIRTHYR_Get(CLIENT_Rec)

Charles

Re: ADATA dump utility [was: RE: Determining a group item]

[Farley, Peter x23353]

Understood, and thanks for the reply.

Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Charles Mills
Sent: Sunday, January 2, 2022 7:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 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

[Charles Mills]

There is an OOP concept called an accessor or getter. I am not finding a 
succinct definition on the Web but perhaps you can.

Anyway, as an alternative to generating the four fields you describe below, you 
might consider generating accessor routines. (This is on the output side of 
things and independent of AREAD, ADATA or SYSPRINT input.)

Assume the following is the record to be accessed from Rexx:

CLIENT   DSECT
LASTNAME DSCL16
FRSTNAME DSCL12
ZIPCODE  DSF
BIRTHYR  DSH

The program would return the following Rexx code (untested):

LASTNAME_Get: Return SubStr(Arg(1), 1, 16)
FRSTNAME_Get: Return SubStr(Arg(1), 17, 12)
ZIPCODE_Get: Return C2D(SubStr(Arg(1), 29, 4))
BIRTHYR_Get: Return C2D(SubStr(Arg(1), 33, 2))

Now your Rexx application programmer could code lines like the following 
(assuming CLIENT_Rec contained a CLIENT record):

Say "Client" LASTNAME_Get(CLIENT_Rec) "was born in" BIRTHYR_Get(CLIENT_Rec)

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Joseph Reichman
Sent: Sunday, January 2, 2022 7:07 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: 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

[Charles Mills]

I agree so much with what Peter says that I would do it manually before I would 
try to guess at how the assembler did things.

I don't see how modifying some macro to use AREAD is less effort than running 
the assembly and capturing the SYSADATA or SYSPRINT. You can easily "filter" 
ADATA on a particular DSECT name. (My program did that.) Probably the same 
would be true for SYSPRINT, but I have not thought about it.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Joseph Reichman
Sent: Monday, January 3, 2022 6:01 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Determining a group item

Peter 

The data is the layout of a VB file it doesn’t have orgs for group items has 0 
or nothing 

What I am trying and am not sure if I will succeed is read in the data via 
AREAD 
Using ADATA is not practical as there isn’t 
Production adata file of the record layout 
I could haphazardly take a production program and look for the esid of that 
copybook but it seems like overkill   

I’m in a testing group whose members know little assembler 
Rexx is used to validate data for instance when the government issues a 
stimulus payment 
The production record layout is VB with different sections 
What I am attempting is to generate and populate Rexx variables with the same 
name/symbols as that of assembler and corresponding value from the record 


Just had an idea for an RFE a debugger for the conditional assembly 

Thanks 

> On Jan 3, 2022, at 8:32 AM, Peter Relson  wrote:
> 
> Joe,
> 
> I can all but guarantee that trying to derive the offsets and lengths from 
> the source will miss edge cases that the assembler deals with. ORG is a 
> simple example of something that can be not overly straightforward.
> 
> That is why looking at ADATA (or a listing) has a big advantage -- you are 
> utilizing information produced by the program responsible for dealing with 
> the subtleties.
> 
> Peter Relson
> z/OS Core Technology Design

Re: Determining a group item

[Joseph Reichman]

Peter 

The data is the layout of a VB file it doesn’t have orgs for group items has 0 
or nothing 

What I am trying and am not sure if I will succeed is read in the data via 
AREAD 
Using ADATA is not practical as there isn’t 
Production adata file of the record layout 
I could haphazardly take a production program and look for the esid of that 
copybook but it seems like overkill   

I’m in a testing group whose members know little assembler 
Rexx is used to validate data for instance when the government issues a 
stimulus payment 
The production record layout is VB with different sections 
What I am attempting is to generate and populate Rexx variables with the same 
name/symbols as that of assembler and corresponding value from the record 


Just had an idea for an RFE a debugger for the conditional assembly 

Thanks 

> On Jan 3, 2022, at 8:32 AM, Peter Relson  wrote:
> 
> Joe,
> 
> I can all but guarantee that trying to derive the offsets and lengths from 
> the source will miss edge cases that the assembler deals with. ORG is a 
> simple example of something that can be not overly straightforward.
> 
> That is why looking at ADATA (or a listing) has a big advantage -- you are 
> utilizing information produced by the program responsible for dealing with 
> the subtleties.
> 
> Peter Relson
> z/OS Core Technology Design

Re: Determining a group item

[Peter Relson]

Joe,

I can all but guarantee that trying to derive the offsets and lengths from 
the source will miss edge cases that the assembler deals with. ORG is a 
simple example of something that can be not overly straightforward.

That is why looking at ADATA (or a listing) has a big advantage -- you are 
utilizing information produced by the program responsible for dealing with 
the subtleties.

Peter Relson
z/OS Core Technology Design

Re: ADATA dump utility [was: RE: Determining a group item]

[Martin Trübner]

Peter,

nice idea- but... have a look:

Here is my definition that defines what data structures I want (and of 
course these are processed)


in the ADEXIT. If you write a stand-alone program, I imagine it is 
pretty much the same logic.


 ASMADATA PRINT=NOGEN,    *
AID=NO, *
   AOPT=NO,  Options File Information  *
   COMPUNIT=NO,  Compilation Unit Start/End    *
   DCDS=YES, DC/DS DSECT (Type X'0034')    *
   DCX=YES,  Duplication Extension DSECT(Type X'0035') *
   ESD=YES,  ESD DSECT (Type X'0020')  *
   JID=YES,  Job Identification DSECT (Type X'')   *
   MACH=YES, Machine Instruction DSECT (Type X'0036')  *
   MXREF=NO, Macro and Copy Code Source Summary X'0060'*
   MXREFX=NO,    Macro/Copy XReference DSECT (Type X'0062')*
   OPT=NO,   Options DSECT (Type X'0010')  *
   OUTPUT=NO,    Output File DSECT (Type X'000A')  *
   RLD=NO,   RLD DSECT (Type X'0040')  *
   RXREF=NO, Register XREFe DSECT (Type X'0045')   *
   SOURCE=YES,   Source Analysis DSECT (Type X'0030')  *
   SRCERR=YES,   Source Error DSECT (Type X'0032') *
   STATS=YES,    Statistics DSECT (Type X'0090')   *
   SYM=YES,  Symbol DSECT (Type X'0042')   *
   USER=NO,  User Data Record DSECT (Type X'0070')  *
   USING=YES,    Using Map DSECT (Type X'0080')    *
   XREF=NO   Symbol XREF DSECT (Type X'0044')


for some (i.e.SRCERR) I only take the sheer presence to abort collection 
of data (since a program with error during compile can not be debugged). 
Others there is a more elaborated routine (i.e. DCDS)


I have no problem publishing initial or the handling routines of 
specific record- but there are in no way a complete program for any 
purpose. They will be snippets of a working program. They can be taken 
as starting point for you own routine (i.e. the parser that Charles 
suggested).



The program gets control from the HLASM for this

OPEN,CLOSE,WRITE, PROCESS


I have no clue (would have to RTFM) what PROCESS is- I handle it with 
this message:


'we never process any records(wrong call)'


The others are obvious.


Almost all processing is done in the WRITE part- Once the record-type is 
identified it is a simple transformation of the incoming structure into 
what you need on the outside. My program to extract all data needed for 
debugging which is


-the compile listing as the human sees it (=for stepping thru the code)

-defined structures (DS and DC/DSECT) (=for showing structures with 
names+content)


The information I needed was sometimes spread over multiple 
record-types, but no major hurdles.


The ADEXIT is little under 500 cards long


Hope this helps


Martin