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

Re: Determining a group item

[Abe Kornelis]

Joseph,

you mentioned:
> I can subscript the setc symbol from the AREAD 

Using created set symbols may be more efficient than using a subscripted
array.
Both in terms of run-time efficiency and in terms of
programming/maintenance effort.

Just my tuppence... And a happy & healthy 2022 for all!

Kind regards,
Abe Kornelis
==

Re: Determining a group item

[Joseph Reichman]

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 do &lenvar   SETA 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

[Charles Mills]

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]

[Charles Mills]

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

[Joseph Reichman]

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

[Steve Smith]

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]

[Steve Smith]

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]

[Farley, Peter x23353]

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

[Joseph Reichman]

The main thing I am not sure of is when you do AREAD NOSTMT NOPRINT seems to 
imply it just reads next sysin but doesn’t generate any code/data in that case 
I see no problem using it to do what I want 

Otherwise not sure 

Thanks 



> On Jan 2, 2022, at 12:08 PM, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
> 
>> 
>> 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 Gilmartin]

> 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

[Martin Trübner]

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

[Joseph Reichman]

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

[Paul Gilmartin]

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

[Martin Trübner]

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

Re: Determining a group item

[Joseph Reichman]

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  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.MACLIBSystem macros
> //SYSPUNCH DD  DUMMY
> //SYSINDD  *
>   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  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  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  Addr1Addr2Stmt   Source Stat

Re: Determining a group item

[Charles Mills]

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.MACLIBSystem macros
//SYSPUNCH DD  DUMMY
//SYSINDD  *
   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  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  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  Addr1Addr2Stmt   Source Statement
>>  0046  1 TEST DSECT ,
>>  4040404040404040  2 X1   DC 7CL10' '
>> 0046   3 X2   DC 0CL20' '
>> 0046  4 GROUP1   EQU X1,*-X1,C'C'
>>   5  End   ,
>> 
>>Symbol Cross Reference
>> SymbolLengthValue Id   Type Asm  Program   Defn References
>> GROUP170  C   

Re: Determining a group item

[Joseph Reichman]

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  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  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  Addr1Addr2Stmt   Source Statement
>>  0046  1 TEST DSECT ,
>>  4040404040404040  2 X1   DC 7CL10' '
>> 0046   3 X2   DC 0CL20' '
>> 0046  4 GROUP1   EQU X1,*-X1,C'C'
>>   5  End   ,
>> 
>>Symbol Cross Reference
>> SymbolLengthValue Id   Type Asm  Program   Defn References
>> GROUP170  C   4
>> TEST   1  J   1
>> X110  C  C2  4
>> X220 0046 C  C3
>> 
>>Dsect Cross Reference
>> Dsect  Length  Id  Defn  Con  Member
>> TEST  0046    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 exp

Re: Determining a group item

[Charles Mills]

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  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  Addr1Addr2Stmt   Source Statement
>  0046  1 TEST DSECT ,
>  4040404040404040  2 X1   DC 7CL10' '
> 0046   3 X2   DC 0CL20' '
>  0046  4 GROUP1   EQU X1,*-X1,C'C'
>5  End   ,
> 
> Symbol Cross Reference
> SymbolLengthValue Id   Type Asm  Program   Defn References
> GROUP170  C   4
> TEST   1  J   1
> X110  C  C2  4
> X220 0046 C  C3
> 
> Dsect Cross Reference
> Dsect  Length  Id  Defn  Con  Member
> TEST  0046    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.

Re: Determining a group item

[Paul Gilmartin]

On Dec 30, 2021, at 16:25:27, Joseph Reichman wrote:
> 
> You think processing adata is simpler I mean they data names are not in  
> order 
>  
Oh, they're in order.  The order is just undocumented.

>> On Dec 30, 2021, at 5:41 PM, Bob Raicer wrote:
>> ...
>> For reasons lost in antiquity, an explicitly specified Length value
>> must be positive, e.g., CL0' ' is invalid.
>>  
I have long suspected that is to support storing the biased length
in  single byte, as in SS instructions.  Storage was precious.

>> ..., the length attribute of a DSECT ... is always 1 ...
>>  
Bummer.

-- gil

Re: Determining a group item

[Joseph Reichman]

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  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  Addr1Addr2Stmt   Source Statement
>  0046  1 TEST DSECT ,
>  4040404040404040  2 X1   DC 7CL10' '
> 0046   3 X2   DC 0CL20' '
>  0046  4 GROUP1   EQU X1,*-X1,C'C'
>5  End   ,
> 
> Symbol Cross Reference
> SymbolLengthValue Id   Type Asm  Program   Defn References
> GROUP170  C   4
> TEST   1  J   1
> X110  C  C2  4
> X220 0046 C  C3
> 
> Dsect Cross Reference
> Dsect  Length  Id  Defn  Con  Member
> TEST  0046    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.

Re: Determining a group item

[Bob Raicer]

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
     0046  1 TEST DSECT ,
 4040404040404040  2 X1   DC 7CL10' '
0046   3 X2   DC 0CL20' '
     0046  4 GROUP1   EQU X1,*-X1,C'C'
   5  End   ,

    Symbol Cross Reference
Symbol    Length    Value Id   Type Asm  Program   Defn References
GROUP1    70      C   4
TEST   1      J   1
X1    10      C  C    2  4
X2    20 0046     C  C    3

    Dsect Cross Reference
Dsect  Length  Id  Defn  Con  Member
TEST  0046    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.

Re: Determining a group item the entire picture

[Paul Gilmartin]

On Dec 29, 2021, at 10:54:06, Joseph Reichman wrote:
> 
> The data I am trying to access is variable and complex to get too
> 
> Would like to read the asm copybook via assembler AREAD generate and put them 
> into variables with Rexx variable having the same name as the assembler 
>  
Mark Zelden supplies many EXECs to analyze MVS control blocks:

They appear to have been painstakingly hand-cded.  His site seems
to make no mention of ADATA nor of parsing data areas definitions.

-- gil

Re: Determining a group item the entire picture

[Joseph Reichman]

The data I am trying to access is variable and complex to get too

Would like to read the asm copybook via assembler AREAD generate and put them 
into variables with Rexx variable having the same name as the assembler 

Thanks



> On Dec 29, 2021, at 12:00 PM, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
> On Dec 29, 2021, at 07:42:08, Seymour J Metz wrote:
>> 
>> You'd have a similar problem with
>> 
>> FIELDA DS7CL10
>> 
>> The length would be 10, not 70.
>> 
> The OP was envisioning LOCTR.  I'd consider ORG:
> X1   DS7CL10
> X2   EQU   *-X1
> ORG   X1
> FIELDA   DSCLX2
> 
> But it's possible to mislead HLASM lookahead with AIF.
> I once wrote a test that defined a constant as type E
> only if its type attribute was F, or vice versa.  I'd
> prefer that HLASM report an error in such cases rather
> Than guessing incorrectly.
> 
> -- gil

Re: Determining a group item

[Paul Gilmartin]

On Dec 29, 2021, at 07:42:08, Seymour J Metz wrote:
> 
> You'd have a similar problem with
> 
> FIELDA DS7CL10
> 
> The length would be 10, not 70.
>  
The OP was envisioning LOCTR.  I'd consider ORG:
X1   DS7CL10
X2   EQU   *-X1
 ORG   X1
FIELDA   DSCLX2

But it's possible to mislead HLASM lookahead with AIF.
I once wrote a test that defined a constant as type E
only if its type attribute was F, or vice versa.  I'd
prefer that HLASM report an error in such cases rather
Than guessing incorrectly.

-- gil

Re: Determining a group item

[Charles Mills]

ADATA would be a better starting pointIMHO. CharlesSent from a mobile; please 
excuse the brevity.
 Original message From: Joseph Reichman  
Date: 12/29/21  6:34 AM  (GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Subject: Re: Determining a group item Thanks what i am trying to is generate 
Rexx variables and assign them values From an assembler copy book A 0cl or 0 pl 
does not bump up the location counter as I traverse the recordI guess I could 
use LOCTR To see where I am atThanks > On Dec 29, 2021, at 9:19 AM, Seymour J 
Metz  wrote:> > Most programmers would expect these two to be 
equivalent:> >    MVC   foo,bar>    MVC   foo(L'foo),bar> > If you can make a 
business case, I would suggest an RFE for an R (repetition) attribute.> > > --> 
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: Wednesday, December 29, 2021 8:42 AM> To: 
ASSEMBLER-LIST@LISTSERV.UGA.EDU> Subject: Determining a group item> > Is there 
any way of determine a group item> > I was always under the impression that> > 
For instance FIELDA DS    0CL10> The L’FIELDA length would by zero> > Just 
ran an assembly and did a SETA &A L’FIELDA and then.   DC F’&A’ and it was 
10> > So my question becomes is there any way of determining a group item> > 
Thanks

Re: Determining a group item

[Joseph Reichman]

Thanks 


> On Dec 29, 2021, at 10:34 AM, Jonathan Scott  
> wrote:
> 
> There is no current way to determine the duplication factor
> (also known as the multiplicity) using the conditional assembly
> language.  This is a known requirement for which the suggested
> solution is a new SYSATTRD function (for "duplication factor"),
> which would probably return the factor if already defined or 1
> by default, but we haven't yet got round to it.
> 
> The duplication factor is however available in the ADATA DC/DS
> record, which is probably the best method of obtaining that
> information for an existing data structure.
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: Determining a group item

[Jonathan Scott]

There is no current way to determine the duplication factor
(also known as the multiplicity) using the conditional assembly
language.  This is a known requirement for which the suggested
solution is a new SYSATTRD function (for "duplication factor"),
which would probably return the factor if already defined or 1
by default, but we haven't yet got round to it.

The duplication factor is however available in the ADATA DC/DS
record, which is probably the best method of obtaining that
information for an existing data structure.

Jonathan Scott, HLASM
IBM Hursley, UK

Re: Determining a group item

[Joseph Reichman]

You are correct Sir 

Let me look at LOCTR and see if it can help

Thanks 



> On Dec 29, 2021, at 9:42 AM, Seymour J Metz  wrote:
> 
> You'd have a similar problem with
> 
> FIELDA DS7CL10
> 
> The length would be 10, not 70.
> 
> 
> --
> 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: Wednesday, December 29, 2021 9:34 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Determining a group item
> 
> Thanks what i am trying to is generate Rexx variables and assign them values 
> From an assembler copy book
> 
> A 0cl or 0 pl does not bump up the location counter as I traverse the record
> 
> I guess I could use LOCTR
> 
> To see where I am at
> 
> Thanks
> 
> 
> 
>> On Dec 29, 2021, at 9:19 AM, Seymour J Metz  wrote:
>> 
>> Most programmers would expect these two to be equivalent:
>> 
>>   MVC   foo,bar
>>   MVC   foo(L'foo),bar
>> 
>> If you can make a business case, I would suggest an RFE for an R 
>> (repetition) attribute.
>> 
>> 
>> --
>> 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: Wednesday, December 29, 2021 8:42 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Determining a group item
>> 
>> Is there any way of determine a group item
>> 
>> I was always under the impression that
>> 
>> For instance FIELDA DS0CL10
>> The L’FIELDA length would by zero
>> 
>> Just ran an assembly and did a SETA &A L’FIELDA and then.   DC F’&A’ and 
>> it was 10
>> 
>> So my question becomes is there any way of determining a group item
>> 
>> Thanks

Re: Determining a group item

[Seymour J Metz]

You'd have a similar problem with

FIELDA DS7CL10

The length would be 10, not 70.


--
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: Wednesday, December 29, 2021 9:34 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Determining a group item

Thanks what i am trying to is generate Rexx variables and assign them values 
From an assembler copy book

A 0cl or 0 pl does not bump up the location counter as I traverse the record

I guess I could use LOCTR

To see where I am at

Thanks



> On Dec 29, 2021, at 9:19 AM, Seymour J Metz  wrote:
>
> Most programmers would expect these two to be equivalent:
>
>MVC   foo,bar
>MVC   foo(L'foo),bar
>
> If you can make a business case, I would suggest an RFE for an R (repetition) 
> attribute.
>
>
> --
> 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: Wednesday, December 29, 2021 8:42 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Determining a group item
>
> Is there any way of determine a group item
>
> I was always under the impression that
>
> For instance FIELDA DS0CL10
> The L’FIELDA length would by zero
>
> Just ran an assembly and did a SETA     &A L’FIELDA and then.   DC F’&A’ and 
> it was 10
>
> So my question becomes is there any way of determining a group item
>
> Thanks

Re: Determining a group item

[Joseph Reichman]

Thanks what i am trying to is generate Rexx variables and assign them values 
From an assembler copy book 

A 0cl or 0 pl does not bump up the location counter as I traverse the record

I guess I could use LOCTR 

To see where I am at

Thanks 



> On Dec 29, 2021, at 9:19 AM, Seymour J Metz  wrote:
> 
> Most programmers would expect these two to be equivalent:
> 
>MVC   foo,bar
>MVC   foo(L'foo),bar
> 
> If you can make a business case, I would suggest an RFE for an R (repetition) 
> attribute.
> 
> 
> --
> 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: Wednesday, December 29, 2021 8:42 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Determining a group item
> 
> Is there any way of determine a group item
> 
> I was always under the impression that
> 
> For instance FIELDA DS0CL10
> The L’FIELDA length would by zero
> 
> Just ran an assembly and did a SETA &A L’FIELDA and then.   DC F’&A’ and 
> it was 10
> 
> So my question becomes is there any way of determining a group item
> 
> Thanks

Re: Determining a group item

[Seymour J Metz]

Most programmers would expect these two to be equivalent:

MVC   foo,bar
MVC   foo(L'foo),bar

If you can make a business case, I would suggest an RFE for an R (repetition) 
attribute.


--
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: Wednesday, December 29, 2021 8:42 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Determining a group item

Is there any way of determine a group item

I was always under the impression that

For instance FIELDA DS0CL10
The L’FIELDA length would by zero

Just ran an assembly and did a SETA &A L’FIELDA and then.   DC F’&A’ and it 
was 10

So my question becomes is there any way of determining a group item

Thanks

Determining a group item

[Joseph Reichman]

Is there any way of determine a group item 

I was always under the impression that 

For instance FIELDA DS0CL10
The L’FIELDA length would by zero

Just ran an assembly and did a SETA &A L’FIELDA and then.   DC F’&A’ and it 
was 10 

So my question becomes is there any way of determining a group item

Thanks