Re: Relation between ASMLANGX and EQALANGX

[Joseph Reichman]

Seymour when I was I. Development they encouraged me to stop using TSO TEST
and use to debug tool let me look at my assembly JCL




On Thu, May 16, 2024 at 11:51 AM Seymour J Metz  wrote:

> The HLASM Toolkit includes ASMLANGX and the z/OS debugger includes
> EQALANGX; are their outputs interchangeable, that is, can ASMIDF, ASMIDFB
> and EQANMDBG use the output from either, or does ASMIDF have to use the
> output from ASMLANGX and EQANMDBG have to use the output of EQALANGX?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

Re: IEABRC anomaly

[Joseph Reichman]

There is a B2D2 there just the mask is zero 
So it falls thru 

> On May 1, 2024, at 11:06 AM, Pieter Wiid  wrote:
> 
> NOP translates to BC 0
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, 01 May 2024 16:21
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: IEABRC anomaly
> 
>> On 5/1/24 07:56:17, Seymour J Metz wrote:
>> It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a 
>> feature?
>> .
> Does NOP depend on a base register?
> 
> --
> gil
> 
> 
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com

Re: Setting &sysect as CSECT or on using

[Joseph Reichman]

I understand if I want to make it work I’ll have to break up the macro into 
parts finish the fest after I have a CSECT statement 

Thanks 

> On Dec 20, 2023, at 11:18 AM, Jonathan Scott  
> wrote:
> 
> It is clearly documented that &SYSECT is set to the current
> section name on entry to the macro and is not updated if the
> macro changes section.
> 
> https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=symbols-sysect-system-variable-symbol
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: Setting &sysect as CSECT or on using

[Joseph Reichman]

I’m at work right now will get back to you later 

Thank you 

> On Dec 20, 2023, at 10:03 AM, Phil Smith III  wrote:
> 
> Joe,
> 
> 
> 
> Your posts are incoherent, and lack much supporting detail necessary for 
> anyone to help you. Folks are trying anyway, but you're wasting their time 
> and yours. Please post a description and sample code so we can understand, as 
> others have repeated asked. A whole sample program can be quite short: just 
> take what you have, copy it, and start deleting all the guts that aren't 
> relevant. Then verify that the problem still occurs. There's a decent chance 
> that in doing so, you'll figure it out yourself, so this is always a 
> worthwhile exercise: I can't count the number of times that's happened to me!

Re: Setting &sysect as CSECT or on using

[Joseph Reichman]

I modified cbt file 192 

Member GRECOV

The members have a MODULE 

Macro it established a base reg and CSECT work area etc 

The &BASE was not sublist ( for more than one base reg ) 

I modified that as GRECOV went to two base regs 

The sublist code was after the module macro had established a CSECT name 

However since upon entry to the module macro as ( TONY H) pointed out there was 
no CSECT 

&SYSECT was null

Thanks 

> On Dec 20, 2023, at 3:28 AM, Binyamin Dissen  
> wrote:
> 
> You have been given good advice.
> 
> Create a minimal program that shows the problem. Based on the expansion shown,
> all you need is register equates and the CSECT statement. 
> 
> Source should be:
> 
>   COPY  macroname   -  to place it in the listing
>WHATEVER CSECT
>  USING *,R15
>   macroname parameters
>register equates
>       END
> 
> On Tue, 19 Dec 2023 21:18:05 -0500 Joseph Reichman 
> wrote:
> 
> :>I tried it and and &sysect generated a value 
> :>
> :>> On Dec 19, 2023, at 8:17?PM, Tony Thigpen  wrote:
> :>> 
> :>> ?Did you ever establish the CSECT name with a CSECT statement before your 
> macro?
> :>> 
> :>> Tony Thigpen
> :>> 
> :>> Joe Reichman wrote on 12/19/23 6:33 PM:
> :>>>2420+ PRINT ON
> :>>> 50 B240 00E0   2421+ BAKR  14,0
> :>>> 54 51CF 0  2422+ LAE   12,0(15,0)
> :>>> 58 41A0 CFFF00FFF  2423+ LA10,4095(,12)
> :>>> 5C 41A0 A0011  2424+ LA10,1(,10)
> :>>> 60 B247    2425+ MSTA  0
> :>>>2426+ DROP  15
> :>>>2427+ MHELP 16
> :>>>2428+ USING ,12,10
> :>>> ** ASMA074E Illegal syntax in expression - ,12
> :>>> Here is the macro code
> :>>>DROP  15 DROP ADDRESSING ON ENTRY POINT
> :>>>   MHELP 16
> :>>>   USING &SYSECT,&USING SET ADDRESSING ON BASE REGISTER(SJOER
> :>>> Here is the MHELP dump clearly you can see that &SYSECT is GRECOV
> :>>> THANKS
> :>>>//MHELP ENTRY TO  STORAGE  MODE
> :>>> SYSTEM PARAMETERS:
> :>>> //SYSVAR NAMELNTH  VALUE (5
> :>>> //SYSNDX  004  0005
> :>>> //SYSECT  006  GRECOV
> :>>> //SYSLOC  006  GRECOV
> :>>> //SYSTIME     005  18.04
> :>>> //SYSDATE 008  12/19/23
> :>>> -Original Message-
> :>>> From: IBM Mainframe Assembler List  On
> :>>> Behalf Of Binyamin Dissen
> :>>> Sent: Tuesday, December 19, 2023 6:27 PM
> :>>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> :>>> Subject: Re: Setting &sysect as CSECT or on using
> :>>> You know what you failed to include in the post.
> :>>> 'nuff said.
> :>>> On Tue, 19 Dec 2023 18:12:37 -0500 Joseph Reichman 
> 
> :>>> wrote:
> :>>> :>Hi
> :>>> :>
> :>>> :>When I use the following
> :>>> :> Using &sysect,12,10
> :>>> :>
> :>>> :>&sysect comes up blank even though I know it had been set :>Thanks
> :>>> --
> :>>> Binyamin Dissen  
> http://www.dissensoftware.com
> :>>> Director, Dissen Software, Bar & Grill - Israel
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel

Re: Setting &sysect as CSECT or on using

[Joseph Reichman]

The definition of the macro was before a CSECT was established the macro module 
from file192 established a CSECT 
When I established a CSECT before the macro definition the &sysect picked it up 

> On Dec 19, 2023, at 10:07 PM, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
> On 12/19/23 17:53:53, Joe Reichman wrote:
>> The macro was invoked in the context of unnamed csect However the Macro 
>> established CSECT would having a macro Whitin a macros solve this I guess 
>> the first macro would establish the CSECT allowing me to use &sysect in the 
>> second macro
>> .
> This is confusing.   Please post a complete small program showing
> the problem you see.  PRINT ON,GEN
> 
> If the macros are not standard, supply instream macros.
> 
> --
> gil

Re: Setting &sysect as CSECT or on using

[Joseph Reichman]

I tried it and and &sysect generated a value 

> On Dec 19, 2023, at 8:17 PM, Tony Thigpen  wrote:
> 
> Did you ever establish the CSECT name with a CSECT statement before your 
> macro?
> 
> Tony Thigpen
> 
> Joe Reichman wrote on 12/19/23 6:33 PM:
>>2420+ PRINT ON
>> 50 B240 00E0   2421+ BAKR  14,0
>> 54 51CF 0  2422+ LAE   12,0(15,0)
>> 58 41A0 CFFF00FFF  2423+ LA10,4095(,12)
>> 5C 41A0 A0011  2424+ LA10,1(,10)
>> 60 B247    2425+ MSTA  0
>>2426+ DROP  15
>>2427+ MHELP 16
>>2428+ USING ,12,10
>> ** ASMA074E Illegal syntax in expression - ,12
>> Here is the macro code
>>DROP  15 DROP ADDRESSING ON ENTRY POINT
>>   MHELP 16
>>   USING &SYSECT,&USING SET ADDRESSING ON BASE REGISTER(SJOER
>> Here is the MHELP dump clearly you can see that &SYSECT is GRECOV
>> THANKS
>>//MHELP ENTRY TO  STORAGE  MODE
>> SYSTEM PARAMETERS:
>> //SYSVAR NAMELNTH  VALUE (5
>> //SYSNDX  004  0005
>> //SYSECT  006  GRECOV
>> //SYSLOC  006  GRECOV
>> //SYSTIME 005  18.04
>> //SYSDATE 008  12/19/23
>> -Original Message-
>> From: IBM Mainframe Assembler List  On
>> Behalf Of Binyamin Dissen
>> Sent: Tuesday, December 19, 2023 6:27 PM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: Setting &sysect as CSECT or on using
>> You know what you failed to include in the post.
>> 'nuff said.
>> On Tue, 19 Dec 2023 18:12:37 -0500 Joseph Reichman 
>> wrote:
>> :>Hi
>> :>
>> :>When I use the following
>> :> Using &sysect,12,10
>> :>
>> :>&sysect comes up blank even though I know it had been set :>Thanks
>> --
>> Binyamin Dissen  http://www.dissensoftware.com
>> Director, Dissen Software, Bar & Grill - Israel

Setting &sysect as CSECT or on using

[Joseph Reichman]

Hi 

When I use the following
 Using &sysect,12,10

&sysect comes up blank even though I know it had been set
Thanks 

assembler-list@listserv.uga.edu

[Joseph Reichman]

Anyway using MHELP to dump system variables 

Tried 71 
 Just LCLC

Thanks 

assembler-list@listserv.uga.edu

[Joseph Reichman]

Seymour thanks my feeling exactly I have a ALC cop presentation on macros 
Doing some research 

> On Jun 28, 2023, at 10:46 AM, Seymour J Metz  wrote:
> 
> Yes, it's legal, no, it's not an ordinary symbol in a [LCL|GBL]x, and yes, 
> it's confusing. IMHO it would have been better to accept it but issue a 
> warning.
> 
> 
> From: IBM Mainframe Assembler List  on 
> behalf of Joseph Reichman 
> Sent: Wednesday, June 28, 2023 10:09 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Variable symbol without leading &
> 
> Hi
> Just looked at the doc for LCLC says for variable symbol says can be with or 
> with out leading &
> 
> I did try to assemble a symbol without leading & and it did a assemble 
> however I would think without the leading & it’s an ordinary symbol
> 
> However when I tried to do a SETC against it I got a assembly error
> 
> So my question becomes if you  can declare a variable symbol without a 
> leading &
> But cannt SETC what can it be used for

assembler-list@listserv.uga.edu

[Joseph Reichman]

Thank you 

> On Jun 28, 2023, at 10:17 AM, Dave Clark  wrote:
> 
> "IBM Mainframe Assembler List"  wrote on 
> 06/28/2023 10:09:27 AM:
>> Just looked at the doc for LCLC says for variable symbol says can be
>> with or with out leading &
>> 
>> However when I tried to do a SETC against it I got a assembly error 
> 
> 
>I believe that it means LCLC does not require the leading 
> ampersand but in all other uses the leading ampersand is required -- and 
> it is the same variable.
> 
> 
> Sincerely,
> 
> Dave Clark
> -- 
> int.ext: 91078
> direct: (937) 531-6378
> home: (937) 751-3300
> 
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio  45439  USA
> (937) 294-5331
> 
> 
> 
> 
> 
> *
> This email message and any attachments is for use only by the named 
> addressee(s) and may contain confidential, privileged and/or proprietary 
> information. If you have received this message in error, please 
> immediately notify the sender and delete and destroy the message and all 
> copies. All unauthorized direct or indirect use or disclosure of this 
> message is strictly prohibited. No right to confidentiality or privilege 
> is waived or lost by any error in transmission. 
> *

assembler-list@listserv.uga.edu

[Joseph Reichman]

Hi 
Just looked at the doc for LCLC says for variable symbol says can be with or 
with out leading &

I did try to assemble a symbol without leading & and it did a assemble however 
I would think without the leading & it’s an ordinary symbol 

However when I tried to do a SETC against it I got a assembly error 

So my question becomes if you  can declare a variable symbol without a leading 
& 
But cannt SETC what can it be used for 

Re: Conditional assembly variable scope

[Joseph Reichman]

I think I understand 
Open code is a scope just like a macro is scope 

In order to have the same variable / value in multiple scopes a GBLx is used 

> On Jun 27, 2023, at 1:29 PM, Seymour J Metz  wrote:
> 
> No; if the macro doesn't have GBLx &FOO then it isn't part of the scope of 
> the global &FOO, even if there is a GBLx &FOO in open code. 
> 
> 
> From: IBM Mainframe Assembler List  on 
> behalf of Joseph Reichman 
> Sent: Tuesday, June 27, 2023 12:44 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Conditional assembly variable scope
> 
> Sorry but I don’t follow
> If LCLx &FOO is declared in open code
> And also let’s say assigned a value the scope is the entire assembly
> 
> If GBLx &FOO is declared inside a macro
> And also say set
> 
> It’s scope is too the entire assembly ?
> 
> 
>> On Jun 27, 2023, at 12:09 PM, Seymour J Metz  wrote:
>> 
>> The scope of the global &FOO is those units containing GBLx &FOO, where a 
>> unit is either a macro or the open code.
>> 
>> 
>> From: IBM Mainframe Assembler List  on 
>> behalf of Joseph Reichman 
>> Sent: Tuesday, June 27, 2023 11:30 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Conditional assembly variable scope
>> 
>> Would any know the difference in scope
>> Of a local used in open code and a global used
>> In a macro the both seem to have a scope of the entire assembly

Re: Conditional assembly variable scope

[Joseph Reichman]

Got it thanks 



> On Jun 27, 2023, at 1:09 PM, Jonathan Scott  
> wrote:
> 
> 
>> 
>> Would any know the difference in scope
>> Of a local used in open code and a global used
>> In a macro the both seem to have a scope of the entire assembly
> 
> A local variable is unique to the context where it is defined,
> so a local variable defined in open code applies to all open
> code, and a local variable in a macro is defined only in that
> macro.  If the same name is used for a local variable in a
> different context, it refers to a separate variable.
> 
> A global variable is the same variable in all contexts where it
> is defined.
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: Conditional assembly variable scope

[Joseph Reichman]

Sorry but I don’t follow 
If LCLx &FOO is declared in open code 
And also let’s say assigned a value the scope is the entire assembly 

If GBLx &FOO is declared inside a macro 
And also say set 

It’s scope is too the entire assembly ?


> On Jun 27, 2023, at 12:09 PM, Seymour J Metz  wrote:
> 
> The scope of the global &FOO is those units containing GBLx &FOO, where a 
> unit is either a macro or the open code.
> 
> 
> From: IBM Mainframe Assembler List  on 
> behalf of Joseph Reichman 
> Sent: Tuesday, June 27, 2023 11:30 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Conditional assembly variable scope
> 
> Would any know the difference in scope
> Of a local used in open code and a global used
> In a macro the both seem to have a scope of the entire assembly

Conditional assembly variable scope

[Joseph Reichman]

Would any know the difference in scope 
Of a local used in open code and a global used 
In a macro the both seem to have a scope of the entire assembly 

Re: Can seem to get IDF to display source

[Joseph Reichman]

Thank you 

> On Feb 28, 2023, at 7:10 PM, Farley, Peter 
> <0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote:
> 
> The HLASM "Toolkit Feature Installation and Customization Guide" V1R6 on 
> page 10 of the PDF states:
> 
> Planning to install in the link pack area
> Load modules that are not shipped with the RN attribute are not re-entrant, 
> and
> therefore are not eligible for the LPA. They should not be copied to an LPA 
> library
> or placed in an APF-authorized library.
> Currently no HLASM Toolkit Feature load modules are re-entrant.
> 
> I think that says that you can’t use ASMIDF as an authorized application and 
> therefore you cannot use it on authorized code.
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Assembler List  On 
> Behalf Of Joseph Reichman
> Sent: Tuesday, February 28, 2023 6:49 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Can seem to get IDF to display source
> 
> Thanks 
> 
> I just came across what I think is big impediment got abend 0047 when trying 
> to go to supervisor state from a MODESET
> 
> Is it possible IDF doesn’t run in supervisor state and or key zero 
> 
>> On Feb 28, 2023, at 5:51 PM, Janko Kalinic  wrote:
>> 
>> The SYSCMD exec example in the IDF User Guide comes in handy when you want
>> to jump out of IDF to a TSO command or ISPF Dialog.  You need to allocate
>> F(ASM) to your IDF macro library.
>> 
>> SET IMPMACRO ON
>> SYSCMD ISPSTART PANEL(ISR@PRIM)
>> SYSCMD REVIEW ‘JOER.ASM.SOURCE’
> --
> 
> 
> 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: Can seem to get IDF to display source

[Joseph Reichman]

Thanks 

I just came across what I think is big impediment got abend 0047 when trying to 
go to supervisor state from a MODESET

Is it possible IDF doesn’t run in supervisor state and or key zero 

> On Feb 28, 2023, at 5:51 PM, Janko Kalinic  wrote:
> 
> The SYSCMD exec example in the IDF User Guide comes in handy when you want
> to jump out of IDF to a TSO command or ISPF Dialog.  You need to allocate
> F(ASM) to your IDF macro library.
> 
> SET IMPMACRO ON
> SYSCMD ISPSTART PANEL(ISR@PRIM)
> SYSCMD REVIEW ‘JOER.ASM.SOURCE’

Re: Can seem to get IDF to display source

[Joseph Reichman]

That was it thank you 

> On Feb 27, 2023, at 4:00 PM, Janko Kalinic  wrote:
> 
> 
>> 
>> 
>> After the initial screen try pressing PF1 (StmtStep), then PF9 (DISASM).

Re: External symbol record for CATTR

[Joseph Reichman]

Ok will do 

Regarding your last line you are referring to opening up a ticket.

I was told I could open up a ticket regarding things that didn’t work 
I’m not quite sure what that means 

Thanks 

> On Jan 10, 2023, at 9:17 AM, Peter Relson  wrote:
> 
> Joe,
> 
> Please post a small assembler program that, when you assemble it, has the 
> anomaly you cite. I'd think you could take the Metal C assembler, and strip 
> out most of it.
> 
> The following program, based on the tiny amount of data that you chose to 
> share in your post, when assembled on z/OS shows references to M_WSA in the 
> listing and browsing the ADATA you can also see references to it (types 
> x'20', x'30', x'42', x'44'  -- I'm assuming that the 3rd byte of the record 
> is the "type"):
> 
> GETMAC#C CSECT
> M_WSACATTR  RMODE(ANY),PART(INDEX)
> DS0D
> @1indexPTR DC  (4)X'00'
> M_WSACATTR  RMODE(ANY),PART(HEAD)
> @2INDEXPTR DC  (4)X'00'
> END
> 
> Perhaps try this one yourself and see if it shows the anomaly on  your zPDT 
> setup.
> 
> I would not bet that a zPDT personal license provides access to z/OS service. 
> But I don't know for sure.
> 
> Peter

Re: External symbol record for CATTR

[Joseph Reichman]

I have zdpt personal edition licensce can I report this 

I mean I can open a ticket and in the comments have them assign it to you 

I can upload my sysadata to the ticket opened 
 

> On Jan 9, 2023, at 12:38 PM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Mon, 9 Jan 2023 12:21:58 -0500
> 
> Joseph Reichman  wrote:
>> Just to let you know I searched the sysadata
>> For M_WSA and there was only a source record type 30
>> 
>> There were no type 20 records
> 
> The same information should also be present in the ESD report in
> the listing, before the source and object listing.  Is that as
> expected?
> 
> The version of z/OS should not make any difference; if you are
> getting the alignment warning you have a fairly recent level of
> the assembler.
> 
> I can't think of any reason the ESD records would go missing
> from the SYSADATA file unless you are running with an ADATA exit
> that deliberately filters the output.
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: External symbol record for CATTR

[Joseph Reichman]

Just to let you know I searched the sysadata 
For M_WSA and there was only a source record type 30 

There were no type 20 records 

The code was compiled under z/os 2.4 I’m now running z/os 2.5 B version ADCD 

I have zdpt personal edition 

> On Jan 9, 2023, at 11:24 AM, Jonathan Scott  
> wrote:
> 
> The fact that the alignment warning appears confirms that the
> CATTR statement was processed.  The warning is due to a known
> bug in the C compiler which may well be fixed in the latest
> level, and should be harmless in that it does not affect the
> generated code.
> 
> I'd expect to see M_WSA among the element definition (ED) ESD
> entries for the main section (along with B_IDRL, B_PRV and
> B_TEXT).  It should also similarly appear in the ESD report
> in the listing.
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

External symbol record for CATTR

[Joseph Reichman]

I just compiled a Metal C program and generated sysadata 

I see a number CATTR assembler instructions 
There are 0030 records but I don’t see 0020 external symbol records for the 
CATTR

Re: Debugging Assembler Rexx programs

[Joseph Reichman]

I just made the code le compliant invoked 
CEETEST to get debug tool up from there I should be able to extract register 0


This is the Rexx
Address tso
“Call ‘mylosdlib(Myprog)’ passenvb”



> On Jan 26, 2022, at 7:16 PM, Seymour J Metz  wrote:
> 
> For the newbies, Chuck is the father of the CBT tape, and I for one am 
> grateful.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on 
> behalf of Martin Trübner [mar...@pi-sysprog.de]
> Sent: Wednesday, January 26, 2022 12:24 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Debugging Assembler Rexx programs
> 
>>>   I don't know if he has a version that you could use in z/OS or TSO.
> 
> 
> No - I don't, but a good friend of mine Chuck Arney has a Debugger that
> was written based on the same technique to intercept execution.
> 
> 
> Here is a copy from the website at: 
> http://secure-web.cisco.com/1_IOw9ngPcTbMAlNTR0c9k-ScvI4dvQwST3bXKxfz3VbKJL-2GoAFBmyPnkrfcsaWI82DhorYH4nYgaO2YxWQemdDdPy5jOVJqRINaB26IRfHE6XDD1o1K7BBTFP1gO92vFZYGEz-LObKVtXhVmKh3HhyHtXulCOshFaAHcueqq2Anse1kMz3UQcccjo7hFLpfIIwMAPKQ77bFm_9Y0w7R-vTqmYpoAwqkP7Ibj931GuR36_yKNGfKvzoBdDsFeihvHoVSyMz-kxHtjR5NLKHQEPrQ5Kuu0G_x158ApWPbFBixOcBJmkJnTl-XFm453Fl-1wiYdatCGYQW_fO2UZ1L2eHlRAMIGd8xALvNLhOiZqbOG5Jt-TT1p-HEpi4k5vadzvCyko0AOogxvO-ffUBhv-R92NfPB_fw79AKFEICPjjtofqqjw52E0VScICwkjN/http%3A%2F%2Farneycomputer.com%2F
> 
> 
>  Trap Diagnostic Facility is an innovative z/OS
> assembler debugging facility
> 
> 
> Martin

Re: Debugging Assembler Rexx programs

[Joseph Reichman]

You can do anything without the environment block it’s a catch 22

Going to try IKJTSOEV and maybe the returned the cppl->ect->ECTENVBK will work 

Thanks 



> On Jan 26, 2022, at 12:32 PM, Charles Mills  wrote:
> 
> I have a fair amount of experience writing assembler and calling it from 
> Rexx.
> 
> Is your problem with "getting going" -- the linkage and that sort of thing -- 
> or some logic problem in your assembler once you get going?
> 
> You might try writing the world's simplest assembler program first -- maybe 
> just do nothing except survive the call and return successfully. Get that 
> working.
> 
> Then enhance it to return 'Hello, World!" in the result area. SAY it from 
> your calling Rexx to make sure you got it right.
> 
> And then move forward one step at a time. 
> 
> You have two "non-debugger" options for debugging:
> 
> 1. WTO's. Good especially for tracing how far you got in your logic.
> 2. The old DC H'0' and debug from the dump.
> 
> Charles
> 
> 
> -----Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Wednesday, January 26, 2022 8:35 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Debugging Assembler Rexx programs
> 
> The copy book is assembler 
> It tells me the name of the variable it’s length 
> And it’s offset which would be it’s value 
> 
> I have one Simple question 
> 
> This url
> 
> https://share.confex.com/share/115/webprogram/Handout/Session7691/S7691bla.pdf
> 
> Contains what I want to do it says how to write
> The program if the program is extensive 
> You have to debug it 
> 
> The only way to get the Rexx environment 
> Block 
> 
> Address tso
> “Call ‘myloadlib(myprog) passenvb’
> Passenvb populates register 0 with the address of the envblock
> 
> How would I debug this program
> 
> It tried test ‘mylosdlib(myprog)’ cp
> And used ECTENVBK but now I am getting
> 
> A return code invalid language environment 
> 
> 
> 
>>> On Jan 26, 2022, at 11:16 AM, Paul Gilmartin 
>>> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>>> 
>>> On Jan 26, 2022, at 08:09:14, Joe Reichman wrote:
>>> 
>>> Thanks but that would never here at the IRS this place is highly sensitive 
>>> to anything from the outside
>>> 
>> It's hard for these fora to help you if:
>> 
>> o You can't show the failing code.
>> 
>> o You can't accept working examples from outside.
>> 
>> Must your solution involve Assembler?  Why not keep the data in a file,
>> read it with Rexx and populate the variables with assignment statements
>> or VALUE()?
>> 
>> -- 
>> gil

Re: Debugging Assembler Rexx programs

[Joseph Reichman]

The copy book is assembler 
It tells me the name of the variable it’s length 
And it’s offset which would be it’s value 

I have one Simple question 

This url

https://share.confex.com/share/115/webprogram/Handout/Session7691/S7691bla.pdf

Contains what I want to do it says how to write 
The program if the program is extensive 
You have to debug it 

The only way to get the Rexx environment 
Block 

Address tso
“Call ‘myloadlib(myprog) passenvb’
Passenvb populates register 0 with the address of the envblock

How would I debug this program

It tried test ‘mylosdlib(myprog)’ cp
And used ECTENVBK but now I am getting

A return code invalid language environment 



> On Jan 26, 2022, at 11:16 AM, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
> On Jan 26, 2022, at 08:09:14, Joe Reichman wrote:
>> 
>> Thanks but that would never here at the IRS this place is highly sensitive 
>> to anything from the outside
>> 
> It's hard for these fora to help you if:
> 
> o You can't show the failing code.
> 
> o You can't accept working examples from outside.
> 
> Must your solution involve Assembler?  Why not keep the data in a file,
> read it with Rexx and populate the variables with assignment statements
> or VALUE()?
> 
> -- 
> gil

Debugging Assembler Rexx programs

[Joseph Reichman]

Hi

Don’t know if this is the right forum 

But I’m posting in regards to ASMIDF

I need to debug a program called as such 

Call ‘myloadlib.lib(MYPROG)’ PASSENVB 

I tried running under TSO TEST using CP 
and from there getting the ECT then the ECTENVBK but had problems 

I saw a section in the IDF users guide 

Programs invoked by Rexx (TSO)
But it was only 7 lines with no examples 

More so if ASMIDF can be invoked from a program then after the STM 14 - 12 and 
saving R0 I.e LR R10,R0 I could invoke IDF thdtveoukd be helpful

Thanks 

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: 
> <https://en.wikipedia.org/wiki/Law_of_triviality>.
> 
> -- 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

[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: 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

[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

[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

[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

[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

[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

[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

[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 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

[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

[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

[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

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 

Re: Type attribute for data

[Joseph Reichman]

No just wanted to verify 

Thanks 



> On Dec 28, 2021, at 8:14 PM, Gord Tomlin  
> wrote:
> 
> On 2021-12-28 15:36 PM, Joseph Reichman wrote:
>> I am going through a copy book in a macro
>> Via the AREAD assembler instruction the copy book is a Dsect
>> 
>> It seem whether data is defined ds cl6 or ds pl6 the T’ is always a C if 
>> it’s defined storage
>> as a constant I.E DC   Pl6 would be P
> 
> Is there a question in there somewhere?
> 
> --
> 
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/

Type attribute for data

[Joseph Reichman]

I am going through a copy book in a macro 
Via the AREAD assembler instruction the copy book is a Dsect 

It seem whether data is defined ds cl6 or ds pl6 the T’ is always a C if it’s 
defined storage 
as a constant I.E DC   Pl6 would be P

Thanks 

CSRC4EXP

[Joseph Reichman]

I’m looking at the Parms for this call there is one alet and pointers to the 
anchor, extent and cells 

How can it be the anchor extents in address space and the cells in other

More so can you call CSRC4GET From address space A were the cells reside in B
Thanks 

Re: CATTR for SRB code

[Joseph Reichman]

I thought I could segregate the SRB code which had references to external 
module 
Meaning put the external =V CSRC calls 
And keep it in the same 
Class from the doc it seemed that XATTR would have external module in the same 
class I could then move the entire class to 
CSA 

You seem to say it is not for this purpose
I guess you know best 

Thanks  



> On Nov 23, 2020, at 6:57 AM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Sun, 22 Nov 2020 17:03:38 -0500
> 
> Joe Reichman  writes:
>> I wrapped my SRB code around a CATTR since it going to be moved my question
>> now is to reference the starting address is that a  V con or A con
> 
> I don't know why you would want to use CATTR for this purpose,
> and I cannot think how it would be useful.  CATTR is primarily
> to support compatibility with special classes used by compilers
> (for example metal C), for example to define a Writable Static
> Area (which is only supported in an LE environment) or classes
> containing diagnostic information.
> 
> If you want to divide up an assembly into separate components
> which may be split up by run-time logic, you can simply define
> them as separate CSECTs or RSECTs.
> 
> In general, if a reference is to a separate module, it either
> needs a V-con or an A-con with an EXTRN.  If it is a reference
> to something within the same module (that is, the same assembly)
> it can be an A-con without any EXTRN.
> 
> If the SRB code is going to be moved by run-time logic in your
> code, then obviously the starting address needs to be set
> dynamically to the target location and any addresses within the
> moved code which point within the original must be relocated.
> 
> If you want some SRB code to be in common storage, then you
> should either have it pre-loaded in LPA or you should use a
> LOAD with GLOBAL=YES to load it there as a separate module
> (noting the integrity limitations in that case).
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: CATTR and XATTR

[Joseph Reichman]

I thought the point of the CATTR is to allow to put pieces of code such as the 
external module CSRC4BLD in the same class 



> On Nov 22, 2020, at 10:35 PM, Keven Hall  wrote:
> 
> Any VCon or ACon moved along to CSA with the SRB code will refer to 
> locations in your private area and probably would not resolve satisfactorily 
> in the addres space the SRB is scheduled for execution 
> 
> 
> Keven
> 
>> On Nov 22, 2020, at 21:05, Joseph Reichman  wrote:
>> 
>> It would seem to me that if CATTR segregates the code I should be able to 
>> dine how put the external reference for CSR4BLD in that class
>> 
>> Thanks 
>> 
>> 
>> 
>>>> On Nov 22, 2020, at 10:01 PM, Keven Hall  wrote:
>>> 
>>> If your SRB code needs to be in common storage, maybe an better solution 
>>> might be to put it in a separate module and issue a global or a directed 
>>> LOAD (according to your requirements for module persistence) to put it 
>>> there.  That will also obviate any need to adjust AdCons during relocation 
>>> from private to common storage.
>>> 
>>> 
>>> Keven
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>>> On Nov 22, 2020, at 20:32, Joe Reichman  wrote:
>>>> 
>>>> Hi
>>>> 
>>>> 
>>>> 
>>>> I have SRB code in my Assembly which I segregated with a CLASS via CATTR
>>>> 
>>>> 
>>>> 
>>>> In that SRB routine I am calling CSRC4BLD statically i.e with a VCON
>>>> 
>>>> 
>>>> 
>>>> Since I am going to move this code to CSA I would like the =V(CSRC4BLD) to
>>>> be in the same class where I defined my SRB so when I MVCL the class to CSA
>>>> =V(CSRC4BLD)
>>>> 
>>>> 
>>>> 
>>>> Goes along with the rest of my code
>>>> 
>>>> 
>>>> 
>>>> Thanks
>>>> 
>>>> 

Re: CATTR and XATTR

[Joseph Reichman]

It would seem to me that if CATTR segregates the code I should be able to dine 
how put the external reference for CSR4BLD in that class

Thanks 



> On Nov 22, 2020, at 10:01 PM, Keven Hall  wrote:
> 
> If your SRB code needs to be in common storage, maybe an better solution 
> might be to put it in a separate module and issue a global or a directed LOAD 
> (according to your requirements for module persistence) to put it there.  
> That will also obviate any need to adjust AdCons during relocation from 
> private to common storage.
> 
> 
> Keven
> 
> 
> 
> Sent from my iPhone
> 
>> On Nov 22, 2020, at 20:32, Joe Reichman  wrote:
>> 
>> Hi
>> 
>> 
>> 
>> I have SRB code in my Assembly which I segregated with a CLASS via CATTR
>> 
>> 
>> 
>> In that SRB routine I am calling CSRC4BLD statically i.e with a VCON
>> 
>> 
>> 
>> Since I am going to move this code to CSA I would like the =V(CSRC4BLD) to
>> be in the same class where I defined my SRB so when I MVCL the class to CSA
>> =V(CSRC4BLD)
>> 
>> 
>> 
>> Goes along with the rest of my code
>> 
>> 
>> 
>> Thanks
>> 
>> 

Re: CATTR usage

[Joseph Reichman]

Thanks 

I seen it with METAL C using far pointers 
The only reason I can imagine the use of class is for using  the Q con to get 
an offset 
As I think Q con only supports DSECT DXD or sections in class names 


Thanks 

> On Nov 22, 2020, at 12:04 PM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Sun, 22 Nov 2020 11:35:41 -0500
> 
> Joe Reichman  writes:
>> Asking a few questions to see I understand the usage of CATTR
>> ...
> 
> CATTR is managed in the same way as other location counters such
> as CSECT and LOCTR.
> 
> With GOFF, each new CSECT statement starts an element whose
> class name will be filled in later as B_TEXT and whose section
> name is the same as the CSECT name.  It also generates a symbol
> definition associating the CSECT name as an external name with
> the start of the element.  Coding CATTR starts a new element
> whose class name is given by the name field and which also
> belongs the current section (given by the current CSECT name).
> Do not attempt to specify class name B_TEXT explicitly for any
> purpose as this is not supported by HLASM and will probably
> cause errors at bind time.
> 
> You can resume any existing location counter in the usual way
> (for example by a CSECT or LOCTR statement with the original
> name) to switch away from that element, and you can use CATTR
> again with the same name to resume the element.
> 
> Uses for CATTR are rare, as it is primarily used to support
> compatibility with classes generated by compilers for special
> purposes.  I certainly wouldn't recommend it in this case.
> 
> All normal (sequential) I/O processing can be performed in
> 31-bit mode nowadays.  The only aspect which requires 24-bit
> storage is the DCB.  Since the DCB should be in dynamic storage
> rather than part of the program, that means you should acquire
> the relevant storage with LOC=BELOW.  Exit addresses such as
> EODAD= should be specified via a DCBE to support 31-bit mode.
> 
> If you really need separate loadable sections in 24-bit and
> 31-bit storage, just use a separate CSECT and specify the binder
> option RMODE(SPLIT).
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: Finding abending PSW and registers

[Joseph Reichman]

I’m taking a snapx dump of the SDWA don’t want to get involved with EREP



> On Jul 8, 2020, at 1:43 PM, Charles Mills  wrote:
> 
> Me, personally? It does not ring a bell.
> 
> I have an atypical debugging approach. I avoid dumps if at all possible. I 
> have other approaches -- too long a story for a mailing list e-mail -- that 
> work for me.
> 
> In the product I fairly recently developed and supported yes, in the event of 
> an ESTAEX or FRR exit, we formatted some SDWA fields and logged them. I don't 
> see SDWARBAD in there.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Wednesday, July 8, 2020 10:21 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Finding abending PSW and registers
> 
> Finding the right registers is the most important thing in recovery specially 
> if you do a retry 
> Charles have you ever used SWDARBAD ( when available to find the program 
> registers looking for your program name in CDNAME )

Re: Finding abending PSW and registers

[Joseph Reichman]

Finding the right registers is the most important thing in recovery specially 
if you do a retry 
Charles have you ever used SWDARBAD ( when available to find the program 
registers looking for your program name in CDNAME )



> On Jul 8, 2020, at 12:15 PM, Charles Mills  wrote:
> 
> I would guess you can do an RFE for almost anything.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Wednesday, July 8, 2020 6:00 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Finding abending PSW and registers
> 
> The error was in the wait module however EC2 and SDWSRSV was where in my 
> program I issued the wait 
> 
> Can I do a RFE to Have the SDWARC4 contain 64 bit gpr and PSW for ec2 and 
> SDWASRV registers. 

Re: Finding abending PSW and registers

[Joseph Reichman]

The error was in the wait module however EC2 and SDWSRSV was where in my 
program I issued the wait 

Can I do a RFE to Have the SDWARC4 contain 64 bit gpr and PSW for ec2 and 
SDWASRV registers. 

Thanks 



> On Jul 8, 2020, at 8:35 AM, Peter Relson  wrote:
> 
> 
> Problem is the 64 bit regs and PSW in SDWAXEME are reflecting the
> value of psw, ec1 and SDWAGRSV I need psw ec2 and SDWASRSV 64 bit info
> 
> 
> Another unfounded assertion. You do not need "ec2" and "SDWASRSV 64 bit 
> info".  You might well not fully understand what those are.
> 
> You wrote that you wanted time of error information. You have time of 
> error information.
> 
> Peter Relson
> z/OS Core Technology Design

Finding abending PSW and registers

[Joseph Reichman]

I’m posting this to see if my understanding is correct.

If your program abends lets say from a S0C7, then most likely the abending PSW 
and registers would be at SDWAEC1 and SDWAGR00. If on the in the other the 
abend occurred from a system service your PSW would be SDWAEC2 and SDWASR00. 
This would seem all well and good if I used the old fashion way for calling a 
system service an SVC however most system services now use a PC call in stead 
of an SVC more so if the program name is not available would chaining the RB 
SDWARBAD get me my abending PSW and regs Looking at RBCDE -> CDNAME for my 
program 

Thanks 

Re: Help building a parameter list

[Joseph Reichman]

The call turns the last parameter high order 

Bit on I am using the last parameters as as follows header 
And starting and ending pairs of storage to dump Using LIST parameter on SNAP

Towards that it’s not the last parameter the I need x’80’ bit on but the one 
before the last 

Thanks 



> On Mar 24, 2020, at 9:19 AM, Peter Relson  wrote:
> 
> 
> In case of a bad return code I WTO r15 and r0 in ebcdic and then use the 
> wto message as a header as the first parameter when I build a parameter 
> list to call a program to snap relevant variables the variables in the 
> macro I use to build LIST= parm on the SNAP
> 
> 
> So do that but, within your macro, invoke the CALL macro to do its thing 
> so that you don't have to write that part yourself.
> 
> Peter Relson
> z/OS Core Technology Design

Re: Help building a parameter list

[Joseph Reichman]

In case of a bad return code I WTO r15 and r0 in ebcdic and then use the wto 
message as a header as the first parameter when I build a parameter list to 
call a program to snap relevant variables the variables in the macro I use to 
build LIST= parm on the SNAP

On Mar 23, 2020, at 8:44 AM, Peter Relson  wrote:
> 
> Shmuel is of course correct. &DISP(R1) is an incorrect reference to the 
> "R1" element of &DISP which is not valid syntax, contrast with &DISP(1) 
> for example.
> With the trailing period, &DISP.(R1) says to substitute &DISP and then 
> append (R1).
> 
> But why write this macro at all?
> In what was does the z/OS-provided CALL macro not do exactly what you're 
> trying to do?
> 
> Peter Relson
> z/OS Core Technology Design

Re: Help building a parameter list

[Joseph Reichman]

Thanks 

Joe Reichman
Lead Developer Sam Golob Systems Programming 

71-28 163 rd st apt 1A
Fresh meadows NY 11365

> On Mar 22, 2020, at 11:24 AM, Seymour J Metz  wrote:
> 

Re: BASR to AMODE 64

[Joseph Reichman]

My mistake was jumping the gun and not looking at the reason code 

It clearly stated that S0C4 Reason code 38 
Had to do with AMODE 64 when the high order bit of a 31 bit pointer ( which is 
not part of the address in amode 31 but is in amode 64 ) it is best practice to 
do a LLGTR RX before basring a 31 bit pointer in amode 64 

My fault I gave to slow down look at the doc before I send an e-mail :(



Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Nov 22, 2019, at 7:51 AM, Peter Relson  wrote:
> 
> I continue not to understand why you repeatedly fail to provide the 
> information necessary for the good folks on this list to help you.
> 
> 
> So I have LOAD a module amode 64 rmode 24
> 
> Your module does not need to match the RMODE of your DCB unless your DCB 
> is physically resident in the module, namely your module is not reentrant. 
> 
> 
> 
> After loading I turn the 1 bit to the right off now I have a clean half
> address 
> 
> Perhaps you didn't do what you thought you did.
> 
> 
> when I BASR to it bombs and the PSW has the one bit on
> 
> 
> Show the symptom dump. Show the registers at the time of the error. Show 
> the information from the program check. Show something...
> 
> Peter Relson
> z/OS Core Technology Design

Re: BASR to AMODE 64

[Joseph Reichman]

I understand haven’t program that much in amode 64 

Thanks 



Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Nov 22, 2019, at 5:50 AM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Thu, 21 Nov 2019 22:26:07 -0500
> 
> BASR doesn't switch AMODE.  If you want to switch AMODE you need
> to use BASSM (and return using BSM, as the return address will
> be odd for AMODE 64).
> 
> If you BASR staying in AMODE 64, the high word of the register
> needs to be zero.  If you're not clearing it, the effect will
> depend on what the caller had in it, which may well be different
> in the TEST environment.
> 
>> I have a amode 64 rmode 31 program I would like to do I/O So I have to have
>> the DCB below 16mb So I have LOAD a module amode 64 rmode 24
>> 
>> After loading I turn the 1 bit to the right off now I have a clean half
>> address when I BASR to it bombs and the PSW has the one bit on
>> 
>> A funny thing under TEST making a breaking point at the basr it doesn't
>> happen
> 
> Jonathan Scott, HLASM
> IBM UK, Hursley

Re: Global character not keeping value

[Joseph Reichman]

Thanks let me search the program 





> On Nov 18, 2019, at 8:12 AM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Mon, 18 Nov 2019 07:33:29 -0500
> 
> The only way the value could change is if it is modified by
> another macro (or by an open code GBLC and SETC) after the
> DBGRPRLG and before DBGREPLG. This could for example be another
> DBGRPRLG call without DSA.
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: C DLL Code from Assembler

[Joseph Reichman]

Thanks the program ( source ) I would do this ( call the c exports) is one with 
multiple csects I will look up CEEPIPI

Thanks 




> On Jul 3, 2019, at 5:24 PM, Mike Hochee  wrote:
> 
> You might want to consider looking into CEEPIPI, which allows you to 
> initialize an LE 'umbrella' from a non-LE conforming program and then control 
> the execution of main programs, subprograms, dlls, etc. underneath.
> 
> It is documented in chapter 30 of the LE Programming Guide.
> 
> HTH,
> Mike
> 
> 
> From: IBM Mainframe Assembler List  on 
> behalf of Joseph Reichman 
> Sent: Wednesday, July 3, 2019 4:52 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: C DLL Code from Assembler
> 
> Well there is the first #ifdef
> 
> 
>> On Jul 3, 2019, at 4:29 PM, John Melcher 
>> <0a33cad2fca2-dmarc-requ...@listserv.uga.edu> wrote:
>> 
>> There isn't.  You must instantiate Language Environment by either making 
>> your Assembler Language routine the main() or calling it from a LE enabled 
>> "main".
>> 
>> void  main(char * parm)
>> {
>>   Int rc;
>>    rc = Asmfunc();
>> }
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
>> On Behalf Of Joseph Reichman
>> Sent: Wednesday, July 3, 2019 2:51 PM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: C DLL Code from Assembler
>> 
>> *** External email: Verify sender before opening attachments or links ***
>> 
>> 
>> I saw reference to DLL's in the XL C bookshelf
>> 
>> Unlike Windows there doesn't seem to be a DLLMAIN function
>> 
>> Thanks
>> 
>> 
>> 
>> 
>>>> On Jul 3, 2019, at 3:46 PM, Tony Harminc  wrote:
>>>> 
>>>> On Tue, 2 Jul 2019 at 17:24, Joseph Reichman  wrote:
>>>> 
>>>> I am hoping to have the Assembler Started task code call a C DLL,  On
>>>> the Windows end it would be C/C+ code calling the DLL obviously there
>>>> are differences because of the platform but I am guessing hose call
>>>> be handled by #IFDEF
>>>> 
>>>> In Windows Loading the DLL is a LoadLibrary Api then GetProcAddress
>>>> to get the exports
>>>> 
>>>> I am not sure how to do this in Assembler is there a LoadLibrary
>>>> Macro or a GetProcAddress macro to call the exported function
>>> 
>>> DLLs are discussed in the LE book _Language Environment Programming
>>> Guide_ in Chapter 4. Most of the examples and discussions are about C,
>>> but there are some brief assembler bits. And there is a discussion of
>>> assembler considerations (not just for DLLs) in Chapter 29, including
>>> the various macros you need.
>>> 
>>> To be clear, HLASM *is* explictly a supported language for both
>>> writing and invoking DLLs under LE. See "Support for DLLs" at the very
>>> start of Chapter 4.
>>> 
>>> I haven't played with this for many years, and am not current, but
>>> other people on this list have written about it - maybe John McKown?
>>> And there was the Trainer's Friend guy (Steve Comstock?), who gave
>>> courses on this and related LE matters. He made his course materials
>>> available for sale when he closed the business. Maybe they are still
>>> out there? Ah - I see some of it is now on Amazon. Not free, but maybe
>>> a good deal.
>>> http://TOC.ASG.COM:8080/?dmVyPTEuMDAxJiY1NDU1NmVlYzI3Nzk4NzhlZT01RDFEMDcxOV85OTE1N185NjNfMSYmNTBjMjY5NGQ5NGMxYTRlPTEyMzImJnVybD1odHRwJTNBJTJGJTJGd3d3JTJFdHJhaW5lcnNmcmllbmQlMkVjb20lMkZ6T1MlMkVzaHRtbA==
>>>  I have no connection, etc...
>>> 
>>> Tony H.

Re: C DLL Code from Assembler

[Joseph Reichman]

Well there is the first #ifdef


> On Jul 3, 2019, at 4:29 PM, John Melcher 
> <0a33cad2fca2-dmarc-requ...@listserv.uga.edu> wrote:
> 
> There isn't.  You must instantiate Language Environment by either making your 
> Assembler Language routine the main() or calling it from a LE enabled "main".
> 
> void  main(char * parm)
> {
>Int rc;
> rc = Asmfunc();
> }
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Wednesday, July 3, 2019 2:51 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: C DLL Code from Assembler
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> I saw reference to DLL’s in the XL C bookshelf
> 
> Unlike Windows there doesn’t seem to be a DLLMAIN function
> 
> Thanks
> 
> 
> 
> 
>>> On Jul 3, 2019, at 3:46 PM, Tony Harminc  wrote:
>>> 
>>> On Tue, 2 Jul 2019 at 17:24, Joseph Reichman  wrote:
>>> 
>>> I am hoping to have the Assembler Started task code call a C DLL,  On 
>>> the Windows end it would be C/C+ code calling the DLL obviously there 
>>> are differences because of the platform but I am guessing hose call 
>>> be handled by #IFDEF
>>> 
>>> In Windows Loading the DLL is a LoadLibrary Api then GetProcAddress 
>>> to get the exports
>>> 
>>> I am not sure how to do this in Assembler is there a LoadLibrary 
>>> Macro or a GetProcAddress macro to call the exported function
>> 
>> DLLs are discussed in the LE book _Language Environment Programming 
>> Guide_ in Chapter 4. Most of the examples and discussions are about C, 
>> but there are some brief assembler bits. And there is a discussion of 
>> assembler considerations (not just for DLLs) in Chapter 29, including 
>> the various macros you need.
>> 
>> To be clear, HLASM *is* explictly a supported language for both 
>> writing and invoking DLLs under LE. See "Support for DLLs" at the very 
>> start of Chapter 4.
>> 
>> I haven't played with this for many years, and am not current, but 
>> other people on this list have written about it - maybe John McKown?
>> And there was the Trainer's Friend guy (Steve Comstock?), who gave 
>> courses on this and related LE matters. He made his course materials 
>> available for sale when he closed the business. Maybe they are still 
>> out there? Ah - I see some of it is now on Amazon. Not free, but maybe 
>> a good deal. 
>> http://TOC.ASG.COM:8080/?dmVyPTEuMDAxJiY1NDU1NmVlYzI3Nzk4NzhlZT01RDFEMDcxOV85OTE1N185NjNfMSYmNTBjMjY5NGQ5NGMxYTRlPTEyMzImJnVybD1odHRwJTNBJTJGJTJGd3d3JTJFdHJhaW5lcnNmcmllbmQlMkVjb20lMkZ6T1MlMkVzaHRtbA==
>>  I have no connection, etc...
>> 
>> Tony H.

Re: C DLL Code from Assembler

[Joseph Reichman]

I saw reference to DLL’s in the XL C bookshelf 

Unlike Windows there doesn’t seem to be a DLLMAIN function 

Thanks 




> On Jul 3, 2019, at 3:46 PM, Tony Harminc  wrote:
> 
>> On Tue, 2 Jul 2019 at 17:24, Joseph Reichman  wrote:
>> 
>> I am hoping to have the Assembler Started task code call a C DLL,  On the 
>> Windows end it would be C/C+ code calling the
>> DLL obviously there are differences because of the platform but I am 
>> guessing hose call be handled by #IFDEF
>> 
>> In Windows Loading the DLL is a LoadLibrary Api then GetProcAddress to get 
>> the exports
>> 
>> I am not sure how to do this in Assembler is there a LoadLibrary Macro or a 
>> GetProcAddress macro to call the exported
>> function
> 
> DLLs are discussed in the LE book _Language Environment Programming
> Guide_ in Chapter 4. Most of the examples and discussions are about C,
> but there are some brief assembler bits. And there is a discussion of
> assembler considerations (not just for DLLs) in Chapter 29, including
> the various macros you need.
> 
> To be clear, HLASM *is* explictly a supported language for both
> writing and invoking DLLs under LE. See "Support for DLLs" at the very
> start of Chapter 4.
> 
> I haven't played with this for many years, and am not current, but
> other people on this list have written about it - maybe John McKown?
> And there was the Trainer's Friend guy (Steve Comstock?), who gave
> courses on this and related LE matters. He made his course materials
> available for sale when he closed the business. Maybe they are still
> out there? Ah - I see some of it is now on Amazon. Not free, but maybe
> a good deal. http://www.trainersfriend.com/zOS.shtml I have no
> connection, etc...
> 
> Tony H.

Re: HLASM calling C DLL

[Joseph Reichman]

I think I’ll compile the code on visual studio with #ifdef  
Then upload it 

Thanks 




> On Jul 3, 2019, at 2:46 AM, Mike Hochee  wrote:
> 
> Excellent presentation!
> 
> Thank you Charles
> 
> 
> From: IBM Mainframe Assembler List  on 
> behalf of Joseph Reichman 
> Sent: Tuesday, July 2, 2019 9:38 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: HLASM calling C DLL
> 
> Thanks
> 
> -Original Message-
> From: IBM Mainframe Assembler List  On 
> Behalf Of Jon Perryman
> Sent: Tuesday, July 2, 2019 9:38 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: HLASM calling C DLL
> 
> You can get quickly up to speed on IBM's DLL implementation with the older 
> share presentation at ftp://ftp.software.ibm.com/s390/zos/le/an8130.pdf which 
> shows both sides with examples in several languages (including HLA). For me, 
> it's been several years but it don't remember it being difficult.
>On Tuesday, July 2, 2019, 02:51:38 PM PDT, Joseph Reichman 
>  wrote:
> 
> I got a bounce back trying to reply too many lines
> 
> 
> 
> Charles
> 
> 
> 
> Thanks for the Hyperlink example but I am looking for HLASM doing the 
> LoadLibrary and GetProcAddress

Re: HLASM calling C DLL

[Joseph Reichman]

Thanks

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Jon Perryman
Sent: Tuesday, July 2, 2019 9:38 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM calling C DLL

 You can get quickly up to speed on IBM's DLL implementation with the older 
share presentation at ftp://ftp.software.ibm.com/s390/zos/le/an8130.pdf which 
shows both sides with examples in several languages (including HLA). For me, 
it's been several years but it don't remember it being difficult.
On Tuesday, July 2, 2019, 02:51:38 PM PDT, Joseph Reichman 
 wrote:  
 
 I got a bounce back trying to reply too many lines

 

Charles

 

Thanks for the Hyperlink example but I am looking for HLASM doing the 
LoadLibrary and GetProcAddress

 

 

 
  

HLASM calling C DLL

[Joseph Reichman]

I got a bounce back trying to reply too many lines

 

Charles

 

Thanks for the Hyperlink example but I am looking for HLASM doing the
LoadLibrary and GetProcAddress

 

 

 

Re: C DLL Code from Assembler

[Joseph Reichman]

I have a Z/os Assembler Started task acting as a TCP/IP Server to Windows 
TCP/IP Client the Windows API is in MFC I have the same basic functionality on 
the Assembler Server Start task as the on the Windows Client

I am hoping to have the Assembler Started task code call a C DLL,  On the 
Windows end it would be C/C+ code calling the DLL obviously there are 
differences because of the platform but I am guessing hose call be handled by 
#IFDEF

In Windows Loading the DLL is a LoadLibrary Api then GetProcAddress to get the 
exports

I am not sure how to do this in Assembler is there a LoadLibrary Macro or a 
GetProcAddress macro to call the exported function

Thanks 

 -Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Jon Perryman
Sent: Tuesday, July 2, 2019 4:56 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: C DLL Code from Assembler

 I assume your question has not been answered and you are asking a question 
because something is not plain and simple. Is this about how to call a C 
program/function from assembler? Is this about calling assembler from a C 
program? Is it about calling C++ object methods (functions) from assembler. Are 
you thinking there is a naming conflict or something about binder name 
resolution?
On Tuesday, July 2, 2019, 01:20:24 PM PDT, Joseph Reichman 
 wrote:  
 
 Plain and simple I need to write code the majority of which is same in both a 
windows platform and z/os hence C/C++ I can encapsulate the different function 
and export them 



In z/os it would be called from Assembler in Windows from MFC C/C++

> On Jul 2, 2019, at 4:09 PM, Jon Perryman  wrote:
> 
> This is really vague and I think there may be some misunderstanding of 
> terminology. 
> Why are you asking about Metal/C? Is there some importance to this? MetalC 
> may be missing functions you need. MetalC is an implementation of C that can 
> be used within z/OS (e.g. SMF routines). Several functions are missing 
> because they are not compatible within the OS (e.g. dllload because it does 
> an MVS load).
> Why are you discussing DLL? MetalC can be part of a DLL but a MetalC program 
> is not designed to call a DLL. Other than implementation and benefits of how 
> a specific function is called, this information may be more co ?
> You mention #IFDEF to exclude/include C code but you do not mention how it's 
> important. The information too vague to recommend alternatives. Maybe a C++ 
> object would eliminate the need for it. Maybe a structure with callback 
> addresses would work. 
> You mention I/O and TCP. Also vague as to their importance to your question. 
> I'm guessing that you are asking how to get assembler and C working together. 
> You seem to be saying a z/OS assembler program will call different C 
> functions and a Windows program will call those same C functions. Or maybe 
> you are saying you have a C program that calls different functions based on 
> some data (where z/OS will use an assembler program to get that data).
> If you didn't get the answer you need, then maybe you could restate the 
> question. 
> Regards, Jon.
>  On Monday, July 1, 2019, 02:40:21 PM PDT, Joseph Reichman 
> wrote:
> 
> I have most of it written in Assembler as .a TCP/IP server
> 
> With Windows being the client it issues command to the tcp/ip server 
> Each command is in a CSECT
> 
> 
> In this Assembler CSECT I would like to call the C DLL to open read 
> the file
> 
> In Windows I would be displaying it in a rich edit
> 
> The stream in callback would call the DLL to do the same seems like 
> most of the code is similar besides the actual I/O
> 
> 
> 
> 
>> On Jul 1, 2019, at 5:26 PM, Charles Mills  wrote:
>> 
>> Can you do the whole process in C? When I first tried to move myself 
>> from doing everything in assembler I kept hoping to dimp my toe into 
>> doing little bits and pieces in C, and that never worked out. What 
>> worked out was writing the whole darned thing in C, and then using 
>> assembler for a few little bits and pieces where necessary.
>> 
>> Something AMODE 31 C does wonderfully is dataset I/O, and does it in 
>> a way that is for the most part -- depending on exactly what you are 
>> trying to accomplish -- compatible with Windows C.
>> 
>> Charles
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List 
>> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
>> On Behalf Of Joseph Reichman
>> Sent: Monday, July 1, 2019 2:04 PM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: C DLL Code from Assembler
>> 
>> I am trying to read a VB file
>> 
>> First of my Assembler code is RMODE31 So I anyway have to call 
>> something below the line to op

Re: C DLL Code from Assembler

[Joseph Reichman]

Plain and simple I need to write code the majority of which is same in both a 
windows platform and z/os hence C/C++ I can encapsulate the different function 
and export them 



In z/os it would be called from Assembler in Windows from MFC C/C++

> On Jul 2, 2019, at 4:09 PM, Jon Perryman  wrote:
> 
> This is really vague and I think there may be some misunderstanding of 
> terminology. 
> Why are you asking about Metal/C? Is there some importance to this? MetalC 
> may be missing functions you need. MetalC is an implementation of C that can 
> be used within z/OS (e.g. SMF routines). Several functions are missing 
> because they are not compatible within the OS (e.g. dllload because it does 
> an MVS load).
> Why are you discussing DLL? MetalC can be part of a DLL but a MetalC program 
> is not designed to call a DLL. Other than implementation and benefits of how 
> a specific function is called, this information may be more co ?
> You mention #IFDEF to exclude/include C code but you do not mention how it's 
> important. The information too vague to recommend alternatives. Maybe a C++ 
> object would eliminate the need for it. Maybe a structure with callback 
> addresses would work. 
> You mention I/O and TCP. Also vague as to their importance to your question. 
> I'm guessing that you are asking how to get assembler and C working together. 
> You seem to be saying a z/OS assembler program will call different C 
> functions and a Windows program will call those same C functions. Or maybe 
> you are saying you have a C program that calls different functions based on 
> some data (where z/OS will use an assembler program to get that data).
> If you didn't get the answer you need, then maybe you could restate the 
> question. 
> Regards, Jon.
>  On Monday, July 1, 2019, 02:40:21 PM PDT, Joseph Reichman 
>  wrote:  
> 
> I have most of it written in Assembler as .a TCP/IP server 
> 
> With Windows being the client it issues command to the tcp/ip server 
> Each command is in a CSECT 
> 
> 
> In this Assembler CSECT I would like to call the C DLL to open read the file 
> 
> In Windows I would be displaying it in a rich edit 
> 
> The stream in callback would call the DLL to do the same seems like most of 
> the code is similar besides the actual I/O
> 
> 
> 
> 
>> On Jul 1, 2019, at 5:26 PM, Charles Mills  wrote:
>> 
>> Can you do the whole process in C? When I first tried to move myself from
>> doing everything in assembler I kept hoping to dimp my toe into doing little
>> bits and pieces in C, and that never worked out. What worked out was writing
>> the whole darned thing in C, and then using assembler for a few little bits
>> and pieces where necessary.
>> 
>> Something AMODE 31 C does wonderfully is dataset I/O, and does it in a way
>> that is for the most part -- depending on exactly what you are trying to
>> accomplish -- compatible with Windows C.
>> 
>> Charles
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
>> On Behalf Of Joseph Reichman
>> Sent: Monday, July 1, 2019 2:04 PM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: C DLL Code from Assembler
>> 
>> I am trying to read a VB file 
>> 
>> First of my Assembler code is RMODE31 
>> So I anyway have to call something below the line to open to read to close
>> so each of these could be a DLL export 
>> 
>> The Z/os data I hope to save in a data space 
>> The windows in the global heap 
>> 
>> The processing is similar outside of the I/O
>> Can I use Metal C for this 
>> 
>> 
>> Thanks 
>> 
>> 
>> 
>> 
>>> On Jul 1, 2019, at 4:56 PM, Charles Mills  wrote:
>>> 
>>> I have written a bunch of Z and Windows "system" software in C++ so I
>> think
>>> I am qualified to answer this question.
>>> 
>>> I don't think I know enough to judge the overall practicality of this
>>> approach. Some things are nearly identical on Z and Windows: TCP comes to
>>> mind. Some things are radically different: panel-based user interface
>> comes
>>> to mind.
>>> 
>>> I am not crazy about #ifdef's. I am a C outlier in that regard. I use
>> #ifdef
>>> where I have to but prefer (a.) two different libraries with common
>>> functionality and prototypes; and (b.) a run-time switch (assuming the
>>> bypassed code compiles on both machines and providing the code path is not
>>> super time-critical).
>>> 
>>> I would not preclude the use of 

Re: C DLL Code from Assembler

[Joseph Reichman]

The DLL has nothing do with the I/O as I said I have similar code for both 
Windows and Z/os 




> On Jul 2, 2019, at 12:31 PM, Charles Mills  wrote:
> 
> @Peter is (of course!) correct. I just accepted your premise and went from
> there. You need a 24-bit GETMAIN for the DCB, but a separate DLL or anything
> like that is a way unnecessary over-complication.
> 
> I wrote a paper years ago on converting A/RMODE 24 DCB I/O programs to
> 31-bit. I will send you a copy, and I hereby offer a copy to anyone else who
> wants to write me off-list.
> 
> It is not *directly* relevant -- it is about *converting* an existing DCB
> program to 31-bit -- but it does cover what needs to go where relative to
> the 24-bit line in the DCB world.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Peter Relson
> Sent: Tuesday, July 2, 2019 4:52 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: C DLL Code from Assembler
> 
> 
> First of my Assembler code is RMODE31 
> So I anyway have to call something below the line to open to read to close
> 
> 
> It is not true that you have to call something below the line. Code doing 
> OPEN and CLOSE can be RMODE 31, quite possibly needing to specify MODE=31.
> The DCB itself needs to be below 16M. Even exits via the DCBE can be above 
> 16M.
> 
> Peter Relson
> z/OS Core Technology Design

Re: C DLL Code from Assembler

[Joseph Reichman]

I have most of it written in Assembler as a TCP/IP server 

With Windows being the client it issues command to the tcp/ip server 
Each command is in a CSECT 


In this Assembler CSECT I would like to call the C DLL to open read the file 

In Windows I would be displaying it in a rich edit 

The stream in callback would call the DLL to do the same seems like most of the 
code is similar besides the actual I/O




> On Jul 1, 2019, at 5:26 PM, Charles Mills  wrote:
> 
> Can you do the whole process in C? When I first tried to move myself from
> doing everything in assembler I kept hoping to dimp my toe into doing little
> bits and pieces in C, and that never worked out. What worked out was writing
> the whole darned thing in C, and then using assembler for a few little bits
> and pieces where necessary.
> 
> Something AMODE 31 C does wonderfully is dataset I/O, and does it in a way
> that is for the most part -- depending on exactly what you are trying to
> accomplish -- compatible with Windows C.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Joseph Reichman
> Sent: Monday, July 1, 2019 2:04 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: C DLL Code from Assembler
> 
> I am trying to read a VB file 
> 
> First of my Assembler code is RMODE31 
> So I anyway have to call something below the line to open to read to close
> so each of these could be a DLL export 
> 
> The Z/os data I hope to save in a data space 
> The windows in the global heap 
> 
> The processing is similar outside of the I/O
> Can I use Metal C for this 
> 
> 
> Thanks 
> 
> 
> 
> 
>> On Jul 1, 2019, at 4:56 PM, Charles Mills  wrote:
>> 
>> I have written a bunch of Z and Windows "system" software in C++ so I
> think
>> I am qualified to answer this question.
>> 
>> I don't think I know enough to judge the overall practicality of this
>> approach. Some things are nearly identical on Z and Windows: TCP comes to
>> mind. Some things are radically different: panel-based user interface
> comes
>> to mind.
>> 
>> I am not crazy about #ifdef's. I am a C outlier in that regard. I use
> #ifdef
>> where I have to but prefer (a.) two different libraries with common
>> functionality and prototypes; and (b.) a run-time switch (assuming the
>> bypassed code compiles on both machines and providing the code path is not
>> super time-critical).
>> 
>> I would not preclude the use of "real" (LE) C. One could argue that it is
>> Metal C that has no equivalent on Windows. The equivalents of the services
>> of LE are available from the Windows runtime and OS. Whether it is
> "doable"
>> without LE would depend on what functionality you are trying to
> accomplish.
>> 
>> Charles
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
>> On Behalf Of Joseph Reichman
>> Sent: Monday, July 1, 2019 1:25 PM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: C DLL Code from Assembler
>> 
>> Hi
>> 
>> 
>> 
>> I have some code the majority of which I would like to duplicate on a
>> Windows platform. It occurred to me that if I write the code as  a  C/C++
>> DLL the changes most of which I can segregate with a #ifdef.
>> 
>> Is this doable using Metal C or do I have to use language environment. I
> am
>> looking to call the DLL entry points from assembler 
>> 
>> 
>> 
>> Thanks 

Re: C DLL Code from Assembler

[Joseph Reichman]

I am trying to read a VB file 

First of my Assembler code is RMODE31 
So I anyway have to call something below the line to open to read to close so 
each of these could be a DLL export 

The Z/os data I hope to save in a data space 
The windows in the global heap 

The processing is similar outside of the I/O
Can I use Metal C for this 


Thanks 




> On Jul 1, 2019, at 4:56 PM, Charles Mills  wrote:
> 
> I have written a bunch of Z and Windows "system" software in C++ so I think
> I am qualified to answer this question.
> 
> I don't think I know enough to judge the overall practicality of this
> approach. Some things are nearly identical on Z and Windows: TCP comes to
> mind. Some things are radically different: panel-based user interface comes
> to mind.
> 
> I am not crazy about #ifdef's. I am a C outlier in that regard. I use #ifdef
> where I have to but prefer (a.) two different libraries with common
> functionality and prototypes; and (b.) a run-time switch (assuming the
> bypassed code compiles on both machines and providing the code path is not
> super time-critical).
> 
> I would not preclude the use of "real" (LE) C. One could argue that it is
> Metal C that has no equivalent on Windows. The equivalents of the services
> of LE are available from the Windows runtime and OS. Whether it is "doable"
> without LE would depend on what functionality you are trying to accomplish.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Joseph Reichman
> Sent: Monday, July 1, 2019 1:25 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: C DLL Code from Assembler
> 
> Hi
> 
> 
> 
> I have some code the majority of which I would like to duplicate on a
> Windows platform. It occurred to me that if I write the code as  a  C/C++
> DLL the changes most of which I can segregate with a #ifdef.
> 
> Is this doable using Metal C or do I have to use language environment. I am
> looking to call the DLL entry points from assembler 
> 
> 
> 
> Thanks 

C DLL Code from Assembler

[Joseph Reichman]

Hi

 

I have some code the majority of which I would like to duplicate on a
Windows platform. It occurred to me that if I write the code as  a  C/C++
DLL the changes most of which I can segregate with a #ifdef.

Is this doable using Metal C or do I have to use language environment. I am
looking to call the DLL entry points from assembler 

 

Thanks 

Re: SETRP retry for 64 code

[Joseph Reichman]

I understand 

Thank you 





> On Jun 27, 2019, at 8:43 AM, Peter Relson  wrote:
> 
> 
> I think RTM does a RP and RP is setup for a 16 byte PSW you think they 
> could of found 8 bytes  in SDWARC4
> 
> 
> RTM does not do a "resume program" (RP instruction). Even if this were 
> available for the decades that RTM has supported retry, it would not have 
> been of any help whatsoever.
> 
> If someone makes a business case for needing to retry to a 64-bit address 
> *AND* preserve the contents of all 16 registers, that could be considered 
> for the future.
> But it is fully possibly to accomplish retrying to a 64-bit address, as I 
> have pointed out, as long as you are willing to sacrifice register 15 (or, 
> if providing your own stub, any other register except perhaps register 0).
> 
> There is no available reserved space in SDWARC4, as you could tell by 
> looking. Adding things to the SDWA has cost (including negative 
> ramifications to the amount of storage available below 16M), and 
> potentially significant ramifications to things like the dump header. As a 
> result, updates are not made lightly.
> 
> If you set SDWAG64R15, and identify CVTBSM0F as the retry point, you also 
> need to specify RETRY15=YES on SETRP so that reg 15 is available with your 
> value when the CVTBSM0F BSM is issued.
> 
> Peter Relson
> z/OS Core Technology Design

Re: SETRP retry for 64 code

[Joseph Reichman]

I think RTM does a RP and RP is setup for a 16 byte PSW you think they could of 
found 8 bytes  in SDWARC4





> On Jun 26, 2019, at 3:42 PM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Wed, 26 Jun 2019 09:43:30 -0400
> 
> If you have the linkage stack available and storage containing
> the information needed to resume (such as an SDWA or copy) then
> I think it is possible to create code to resume (at least in
> problem state) at a chosen address with all registers containing
> their original values, original PSW ASC mode, AMODE, condition
> code and program mask, using BAKR and PR.
> 
> I originally wrote some code like this in the 1990s to implement
> a sort of problem-state "must complete" where the original code
> could be resumed for a few instructions from the recovery
> routine, and when it turned off "must complete" it would return
> control to the recovery routine. However, it was never used in
> production, and I'm not sure whether it was even tested, so
> this method comes with no guarantees.
> 
> Basically, you set up the registers that are returned by PR, put
> the resume address in a register that isn't returned by PR,
> issue BAKR to save the resume address, restore the other
> registers and issue PR to resume. However, if you want to do it
> properly with condition code, ASC mode and so on, it's quite
> tricky.
> 
> - Start in primary mode with R1 pointing to the SDWA.
> 
> - Load access registers 2 through 14 (using one of the
>  other registers to address that SDWA section).
> 
> - Load general registers R2 through R14.
> 
> - Get the program mask (with CC) and ASC mode in R15.
> 
> - Get the PSW address and AMODE indicator bits in R0 (because R1
>  and R15 are still needed).
> 
> - Use SAC to set the ASC mode and SPM to set program mask.
> 
> - Copy the PSW instruction address and AMODE from R0 to R15.
> 
> - Issue BAKR R15,0 to stack the PSW and registers R2 to R14.
> 
> - Switch back to primary mode to access SDWA again.
> 
> - Get the program mask again in R15.
> 
> - Repeat the SPM in case PR doesn't restore the condition code
>  (it is undefined whether PR restores the condition code, but
>  it seems reasonable to assume it either takes the stacked
>  one or preserves the current one).
> 
> - Load access registers 15 through 1 from the SDWA, using some
>  other register to address the relevant part.
> 
> - Load general registers R15 through R1.
> 
> - Issue PR to resume execution with original state restored.
> 
> I hope I've remembered that correctly!  I probably have some
> code around somewhere to do that, but I can't remember where.
> 
> Jonathan Scott, HLASM
> IBM Hursley, UK

Re: SETRP retry for 64 code

[Joseph Reichman]

With Peter suggestion you cannt preserve the value of R15 it’s not like the RP 
instruction where you can save the register you are working with what if I have 
a value in R15 that I want its original value 





> On Jun 26, 2019, at 9:39 AM, Tom Marchant 
> <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:
> 
>> On Wed, 26 Jun 2019 07:39:38 -0400, Joseph Reichman wrote:
>> 
>> Ultimitly I would need to do a LPSWE to get to where I need to go 
> 
> No you wouldn't.
> 
>> I guess 64 bit support isn’t there yet 
> 
> I guess you didn't understand Peter's reply.
> 
> What you are asking for as to be able to store 8 bytes of data in a fullword. 
> You can't do that.
> 
> -- 
> Tom Marchant
> 
>>> On Jun 26, 2019, at 7:37 AM, Peter Relson  wrote:
>>> 
>>> 
>>> I was hoping to see STG R4 but the code still had ST R4
>>> 
>>> 
>>> Please re-read what Chuck A wrote.
>>> 
>>> You can’t retry to rmode64 code. You have to have a stub code below the 
>>> bar to retry to and have the stub enter your rmode64 code. 
>>> 
>>> 
>>> There is such a stub provided by the system, CVTBSM0F. 
>>> You set SDWAG6415 to the address you really want to retry to, 
>>> pointer-defined (so for AMODE 64 bit 63 must be on). Identify CVTBSM0F via 
>>> SETRP as the retry address. .
>>> 
>>> Peter Relson
>>> z/OS Core Technology Design

Re: SETRP retry for 64 code the value of 15 is not preserved

[Joseph Reichman]

What if I have a value in 15 I need 

Thanks 




> On Jun 26, 2019, at 7:37 AM, Peter Relson  wrote:
> 
> 
> I was hoping to see STG R4 but the code still had ST R4
> 
> 
> Please re-read what Chuck A wrote.
> 
> You can’t retry to rmode64 code. You have to have a stub code below the 
> bar to retry to and have the stub enter your rmode64 code. 
> 
> 
> There is such a stub provided by the system, CVTBSM0F. 
> You set SDWAG6415 to the address you really want to retry to, 
> pointer-defined (so for AMODE 64 bit 63 must be on). Identify CVTBSM0F via 
> SETRP as the retry address. .
> 
> Peter Relson
> z/OS Core Technology Design
> 

Re: SETRP retry for 64 code

[Joseph Reichman]

Sorry didn’t fully read your response 





> On Jun 26, 2019, at 7:37 AM, Peter Relson  wrote:
> 
> 
> I was hoping to see STG R4 but the code still had ST R4
> 
> 
> Please re-read what Chuck A wrote.
> 
> You can’t retry to rmode64 code. You have to have a stub code below the 
> bar to retry to and have the stub enter your rmode64 code. 
> 
> 
> There is such a stub provided by the system, CVTBSM0F. 
> You set SDWAG6415 to the address you really want to retry to, 
> pointer-defined (so for AMODE 64 bit 63 must be on). Identify CVTBSM0F via 
> SETRP as the retry address. .
> 
> Peter Relson
> z/OS Core Technology Design
> 

Re: SETRP retry for 64 code

[Joseph Reichman]

Ultimitly I would need to do a LPSWE to get to where I need to go I guess 64 
bit support isn’t there yet 


Thanks 





> On Jun 26, 2019, at 7:37 AM, Peter Relson  wrote:
> 
> 
> I was hoping to see STG R4 but the code still had ST R4
> 
> 
> Please re-read what Chuck A wrote.
> 
> You can’t retry to rmode64 code. You have to have a stub code below the 
> bar to retry to and have the stub enter your rmode64 code. 
> 
> 
> There is such a stub provided by the system, CVTBSM0F. 
> You set SDWAG6415 to the address you really want to retry to, 
> pointer-defined (so for AMODE 64 bit 63 must be on). Identify CVTBSM0F via 
> SETRP as the retry address. .
> 
> Peter Relson
> z/OS Core Technology Design
> 

Re: ltorg question

[Joseph Reichman]

Thanks 




> On Jun 25, 2019, at 9:01 PM, Mike Hochee  wrote:
> 
> Hey Joe, 
> 
> The 'D'  (floating point constant type) and F (fixed point constant type) 
> have been around forever. Somewhere between 95-2002 IBM added the 
> type-extension subfield to the DC instruction. As of 2004, D became a valid 
> type-extension, which clarifies characteristics of the type, so in 
> type-extension context, D is doubleword.  ( 
> ftp://public.dhe.ibm.com/software/websphere/awdtools/hlasm/S8164H.pdf  pg 3 )
> 
> For fixed point type double word constants, you can use... ONE   DCFD'1'  
>  
> 
> I was surprised to stumble across this myself some years ago. 
> 
> HTH, 
> Mike 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Tuesday, June 25, 2019 8:35 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: ltorg question
> 
> I see the following literal 
> 
> 
> 
> 41101403=D'1'
> 
> 
> 
> Shouldn't it of translated to 
> 
> 0001
> 
> 
> 
> And the same for -4 
> 
> C1401406=D'-4'
> 
> Shouldn't it of translated to 
> 
> To 
> 
> FFFC
> 
> thanks

Re: ltorg question

[Joseph Reichman]

Thought it was a double word 

As in DS D

> On Jun 25, 2019, at 9:01 PM, Mike Hochee  wrote:
> 
> Hey Joe, 
> 
> The 'D'  (floating point constant type) and F (fixed point constant type) 
> have been around forever. Somewhere between 95-2002 IBM added the 
> type-extension subfield to the DC instruction. As of 2004, D became a valid 
> type-extension, which clarifies characteristics of the type, so in 
> type-extension context, D is doubleword.  ( 
> ftp://public.dhe.ibm.com/software/websphere/awdtools/hlasm/S8164H.pdf  pg 3 )
> 
> For fixed point type double word constants, you can use... ONE   DCFD'1'  
>  
> 
> I was surprised to stumble across this myself some years ago. 
> 
> HTH, 
> Mike 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Tuesday, June 25, 2019 8:35 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: ltorg question
> 
> I see the following literal 
> 
> 
> 
> 41101403=D'1'
> 
> 
> 
> Shouldn't it of translated to 
> 
> 0001
> 
> 
> 
> And the same for -4 
> 
> C1401406=D'-4'
> 
> Shouldn't it of translated to 
> 
> To 
> 
> FFFC
> 
> thanks

ltorg question

[Joseph Reichman]

I see the following literal 

 

41101403=D'1'

 

Shouldn't it of translated to 

0001

 

And the same for -4 

C1401406=D'-4'

Shouldn't it of translated to 

To 

 FFFC

thanks

Re: SETRP retry for 64 code

[Joseph Reichman]

Both my estate and setrp are below the bar however I didn't notice any 
difference in the expansion  of the  setrp macro when processing a setrp for 
amode 31 bit and for amode 64 bit
Meaning when I had retaddr=(R4) in amode 31 the setrp code expanded to  a ST R4 
and the same when I had it RETRYAMODE=64 I was hoping to see STG R4 but the 
code still had ST R4


-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Chuck
Sent: Tuesday, June 25, 2019 4:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SETRP retry for 64 code

You can’t retry to rmode64 code. You have to have a stub code below the bar to 
retry to and have the stub enter your rmode64 code. 

Chuck Arney

> On Jun 25, 2019, at 3:16 PM, Joseph Reichman  wrote:
> 
> Would any one know the parms on the SETRP when retrying 64 bit code It tred 
> 
> 
> 
> I tried   SETRP RC=4,RETADDR=(R4),RETREGS=64,DUMP=NO,RETRYAMODE=64 and I saw
> the same ST  R4 without the RETRYAMODE64 PARAMTER was hoping to see STG  
> 
> 
> 

SETRP retry for 64 code

[Joseph Reichman]

Would any one know the parms on the SETRP when retrying 64 bit code It tred 

 

I tried   SETRP RC=4,RETADDR=(R4),RETREGS=64,DUMP=NO,RETRYAMODE=64 and I saw
the same ST  R4 without the RETRYAMODE64 PARAMTER was hoping to see STG  

 

Re: IDF 64 bit code

[Joseph Reichman]

File 300 on the CBT LG reg 





> On Jun 24, 2019, at 6:41 PM, Tony Harminc  wrote:
> 
>> On Mon, 24 Jun 2019 at 18:18, Janko Kalinic  
>> wrote:
>> 
>> Does this imply that TSO TEST supports 64-bit addressing?
> 
> Sadly, TSO TEST is a *very* long way from supporting 64-bit
> addressing. You can't even list a 64-bit register or enter a 64-bit
> address.
> 
> I like to think of TEST as the "vi" of MVS. It's installed everywhere,
> and klunky and infuriating as it is, you can always rely on being able
> to use it for all kinds of basic things at any site. But as 64-bit
> moves slowly into the mainstream, there is no backup for it.
> 
> Tony H.

Re: IDF 64 bit code

[Joseph Reichman]

Would like to qualify what I just said 

.  I would like to know if IDF can debug  code running in 64bit memory above
4GB.

thanks


-Original Message-
From: IBM Mainframe Assembler List  On
Behalf Of Jonathan Scott
Sent: Sunday, June 23, 2019 4:35 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: IDF 64 bit code

Ref:  Your note of Sun, 23 Jun 2019 09:05:57 -0400

Joseph Reichman  writes:
> Does anyone know if IDF debugs 64 bit code

Yes if on z/OS.

Jonathan Scott, HLASM and Toolkit
IBM Hursley, UK

Re: IDF 64 bit code

[Joseph Reichman]

Thanks 
 Trying it now did IARV64 to get above the bar executable   storage doing a 
BASSM with bit 63 on hope it will follow the code 





> On Jun 23, 2019, at 4:35 PM, Jonathan Scott  
> wrote:
> 
> Ref:  Your note of Sun, 23 Jun 2019 09:05:57 -0400
> 
> Joseph Reichman  writes:
>> Does anyone know if IDF debugs 64 bit code
> 
> Yes if on z/OS.
> 
> Jonathan Scott, HLASM and Toolkit
> IBM Hursley, UK

IDF 64 bit code

[Joseph Reichman]

Hi

Does anyone know if IDF debugs 64 bit code 

Thanks 

Re: Address Space Storage Map Think I got it

[Joseph Reichman]

Seems like LDAEPVTS Starting Extended boundary  and Adding LDAESIZA (size)  
encompasses bot USER and System Private Area 

While it seems like the 24 bit User and System Private Area are Segregated

LDASTRTS Is the beginning of User 24 bit private area LDASIZS is the size Of 
user 24 bit area

LDASTRTA is the start of   24 bit LSQA and LDASIZA is the size of 24 bit LSQA 


Thanks 

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Gord Tomlin
Sent: Monday, May 27, 2019 8:44 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Address Space Storage Map

On 2019-05-27 08:26, Joseph Reichman wrote:
> Hi
> 
>   
> 
>>From the CVT I can get M,F,L  Extended  LPA Start and Ending Storage 
>>Ranges
> and I can also get Nucleus Extended  Read Only and Read Write Starting 
> and ending Ranges
> 
>   
> 
>>From the LDA I can get Private / Extended Starting and Ending Private 
>>Ranges
> 
>   
> 
>>From the GDA I can get SQA  and CSA / Extended Starting and Ending 
>>Ranges
> 
>   
> 
>   
> 
> The Only thing that Escapes me is LSQA
> 
>   
> 
>   
> 
> If anyone can Help would appreciate it
> 
>   
> 
>   
> 
> Thanks
> 
Help us to help you. Please be specific as to the situation in which you want 
to find this information. Is it in a running address space? In a dump? 
Something else?


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

Re: Address Space Storage Map

[Joseph Reichman]

I want to identify an Address I know ultimately I can do a  VSMLIST (that would 
give me allocated and unallocated as well ) But it seems like Every other type 
of Address type Nucleus, CSA. SQA, Private, LPA is identified besides LSQA

thanks 


-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Gord Tomlin
Sent: Monday, May 27, 2019 8:44 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Address Space Storage Map

On 2019-05-27 08:26, Joseph Reichman wrote:
> Hi
> 
>   
> 
>>From the CVT I can get M,F,L  Extended  LPA Start and Ending Storage 
>>Ranges
> and I can also get Nucleus Extended  Read Only and Read Write Starting 
> and ending Ranges
> 
>   
> 
>>From the LDA I can get Private / Extended Starting and Ending Private 
>>Ranges
> 
>   
> 
>>From the GDA I can get SQA  and CSA / Extended Starting and Ending 
>>Ranges
> 
>   
> 
>   
> 
> The Only thing that Escapes me is LSQA
> 
>   
> 
>   
> 
> If anyone can Help would appreciate it
> 
>   
> 
>   
> 
> Thanks
> 
Help us to help you. Please be specific as to the situation in which you want 
to find this information. Is it in a running address space? In a dump? 
Something else?


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

Address Space Storage Map

[Joseph Reichman]

Hi

 

>From the CVT I can get M,F,L  Extended  LPA Start and Ending Storage Ranges
and I can also get Nucleus Extended  Read Only and Read Write Starting and
ending Ranges

 

>From the LDA I can get Private / Extended Starting and Ending Private Ranges

 

>From the GDA I can get SQA  and CSA / Extended Starting and Ending Ranges 

 

 

The Only thing that Escapes me is LSQA 

 

 

If anyone can Help would appreciate it

 

 

Thanks 

 

 

Fwd: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN

[Joseph Reichman]

Begin forwarded message:

> From: Joseph Reichman 
> Date: April 23, 2019 at 10:48:07 AM EDT
> To: Martin Ward 
> Subject: Re: Sysadata symbol and literal cross reference record type x’44’ 
> re-post from IBMMAIN
> 
> I work for the IRS and the tax processing code is HUGE and OLD Assembler 
> 
> I’m on a team doing the documentation in the hope of one day having it in 
> Java 
> 
> I am in charge of tracing the code obviously self modified code has issues 
> Normally a breakpoint on self modified code abends 
> However some one found code that was modified ( a CLC bytes 4 & 5 ) that 
> obviously didn’t blow up but the debugger when retrying the instruction with 
> a breakpoint used the originally 6 bytes of the CLC which produced different 
> results 
> If I could up from identify it would be helpful
> Obviously I could write code when looking at the sysadata was looking maybe 
> the group has an idea  
> 
> Thanks 
> 
> 
> 
>>> On Apr 23, 2019, at 10:36 AM, Martin Ward  wrote:
>>> 
>>> On 22/04/19 22:38, Joseph Reichman wrote:
>>> To be more clear this goes back to the original problem of tracing a
>>> 14 cesct huge piece of code I am wondering if I can identify what
>>> instructions are modified
>> 
>> Software Migrations Ltd. (the company I work for) offers a migration
>> service to convert assembler code into functionally equivalent,
>> structured, efficient and maintainable C or COBOL code.
>> The process is totally automated but custimisable for each project.
>> 
>> Therefore we have to be able to detect and translate any
>> self-modifying code in the listing, wherever possible. We have seen some
>> quite dramatic improvements in performance when migrating assembler
>> code which does a lot of instruction modification!
>> 
>> (Note that the thoretical problem of determining whether a particular
>> program is self-modifying or not is, like the Halting Problem,
>> non-computable. But in practice, all examples of self-modifying code
>> we have encountered can be detected and translated.)
>> 
>> Let me know if you would like to pursue this option.
>> 
>> -- 
>>   Martin
>> 
>> Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
>> G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN

[Joseph Reichman]

Sysadata type 44 will catch most 




> On Apr 22, 2019, at 5:54 PM, Paul Gilmartin 
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> 
>> On 2019-04-22, at 15:38:03, Joseph Reichman wrote:
>> 
>> To be more clear this goes back to the original problem of tracing a 14 
>> cesct huge piece of code I am wondering if I can identify what instructions 
>> are modified
>> 
> There's the empirical approach: Save a copy as REFR; run it; see what breaks.
> (Not 100% effective.)
> (Can you turn REFRPROT on?)
> 
> -- gil

Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN

[Joseph Reichman]

Yes





> On Apr 22, 2019, at 5:25 PM, Robert Netzlof  wrote:
> 
>> On 4/22/19, Keven  wrote:
>> 
>> There’s almost no
>> reason to use self-modifying code that makes sense anymore...
> 
> My impression was that the original poster was hoping to use the
> assembler's facilities to root out instances of self-modifying code in
> existing programs.
> 
> -- 
> Bob Netzlof a/k/a Sweet Old Bob

Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN

[Joseph Reichman]

To be more clear this goes back to the original problem of tracing a 14 cesct 
huge piece of code I am wondering if I can identify what instructions are 
modified

Thanks 


-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Keven
Sent: Monday, April 22, 2019 5:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Sysadata symbol and literal cross reference record type x’44’ 
re-post from IBMMAIN

  
  
  

Using RSECT instead of CSECT would result in your example being flagged 
as non-reentrant (self modifying) but it wouldn’t catch any indirect 
modification such as:LAR5,LABELMVI  0(R5),0LABEL DS 
  0H B. THERE The example would also cause the instruction 
cache line to be flushed which isn’t great.There’s almost no reason to use 
self-modifying code that makes sense anymore...
Keven





  




On Mon, Apr 22, 2019 at 10:06 AM -0500, "Joseph Reichman" 
 wrote:










Had second thoughts and thought this forum to be more appropriate 

Thanks 


J

Begin forwarded message:

> From: Joseph Reichman
> Date: April 22, 2019 at 9:25:10 AM EDT
> To: ibm-m...@listserv.ua.edu
> Subject: Sysadata symbol and literal cross reference record type x’44’
> 
> Hi
> 
> For programs that have self modifying code Adata record type 44 can 
> prove to be a valuable tool in identifying them as the reference flag has a 
> ‘M’
> 
> However I wonder if there is a easy way to identify code that is being 
> modified by location counter I.E MVI *+5,X’00’ and the following instruction 
> is for example B   AROUND
> 
> 
> Thanks

Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN

[Joseph Reichman]

I am trying to determine what instructions are self modifying using sysadata 
wondering if there is any way to determine that



-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Keven
Sent: Monday, April 22, 2019 5:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Sysadata symbol and literal cross reference record type x’44’ 
re-post from IBMMAIN

  
  
  

Using RSECT instead of CSECT would result in your example being flagged 
as non-reentrant (self modifying) but it wouldn’t catch any indirect 
modification such as:LAR5,LABELMVI  0(R5),0LABEL DS 
  0H B. THERE The example would also cause the instruction 
cache line to be flushed which isn’t great.There’s almost no reason to use 
self-modifying code that makes sense anymore...
Keven





  




On Mon, Apr 22, 2019 at 10:06 AM -0500, "Joseph Reichman" 
 wrote:










Had second thoughts and thought this forum to be more appropriate 

Thanks 


J

Begin forwarded message:

> From: Joseph Reichman
> Date: April 22, 2019 at 9:25:10 AM EDT
> To: ibm-m...@listserv.ua.edu
> Subject: Sysadata symbol and literal cross reference record type x’44’
> 
> Hi
> 
> For programs that have self modifying code Adata record type 44 can 
> prove to be a valuable tool in identifying them as the reference flag has a 
> ‘M’
> 
> However I wonder if there is a easy way to identify code that is being 
> modified by location counter I.E MVI *+5,X’00’ and the following instruction 
> is for example B   AROUND
> 
> 
> Thanks

Fwd: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN

[Joseph Reichman]

Had second thoughts and thought this forum to be more appropriate 

Thanks 


J

Begin forwarded message:

> From: Joseph Reichman 
> Date: April 22, 2019 at 9:25:10 AM EDT
> To: ibm-m...@listserv.ua.edu
> Subject: Sysadata symbol and literal cross reference record type x’44’
> 
> Hi
> 
> For programs that have self modifying code 
> Adata record type 44 can prove to be a valuable tool in identifying them as 
> the reference flag has a ‘M’ 
> 
> However I wonder if there is a easy way to identify code that is being 
> modified by location counter I.E MVI *+5,X’00’ and the following instruction 
> is for example B   AROUND
> 
> 
> Thanks

Re: Sysadata to linear

[Joseph Reichman]

Thanks hope to see you next week 
At the TDM in pok







> On Apr 2, 2019, at 8:21 AM, Peter Relson  wrote:
> 
> Loop
> -  Read each individual record (probably into 31-bit storage)
> - Copy into your data space (or 64-bit storage) wherever you want
> EndLoop
> 
> Peter Relson
> z/OS Core Technology Design

Re: Modify ECB COMECBPT Intermittent response

[Joseph Reichman]

Thank you worked now I have to try it a number if times



> On Dec 9, 2018, at 4:03 PM, Charles Mills  wrote:
> 
> That is how I do it:
> 
> EXTRACT COMADDR,FIELDS=COMM,MF=(E,EXTRACTL)
> L R8,COMADDR  GET ADDRESS OF THE AREA
> USING COM,R8  USE R8 AS BASE ADDRESS OF COMM AREA
> ICM   R7,B'',COMCIBPT GET CIB ADDRESS FROM COM AREA
> JZCIBDELET_NoCIB  NO CIB
> 
> QEDIT ORIGIN=COMCIBPT,BLOCK=(R7)
> 
> CIBDELET_NoCIB EQU *
> QEDIT ORIGIN=COMCIBPT,CIBCTR=1
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Sunday, December 9, 2018 12:20 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Modify ECB COMECBPT Intermittent response
> 
> I think that was it 
> 
> From what I understand After getting the CIB address via extract 
> I have to issue 2 QEDIT’s
> 
> The first with a BLOCK parameter to free the start CIB
> The second to a limit on the number if CIB
> L   RX,COMCIBPT
> 1st QEDIT ORIGIN=COMCIBPT,ORIGIN=(RX)
> 2nd QEDIT ORIGIN=COMCIBPT,CIBCTR=4
> Thanks 
> 
> 
> Joe Reichman
> 170-10 73 rd ave 
> Fresh meadows NY 11366
> 
>> On Dec 7, 2018, at 9:27 AM, Joseph Reichman  wrote:
>> 
>> Let me check 
>> Thanks 
>> 
>> 
>> 
>>> On Dec 7, 2018, at 9:20 AM, Charles Mills  wrote:
>>> 
>>> Do you perhaps have a logic error relative to QEDIT? If you don't free the 
>>> CIB you may never get another MODIFY.
>>> 
>>> Charles
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
>>> On Behalf Of Joseph Reichman
>>> Sent: Thursday, December 6, 2018 10:48 AM
>>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>>> Subject: Re: Modify ECB COMECBPT Intermittent response
>>> 
>>> It doesn’t have a wait bit there is only one task waiting on it 
>>> The main task  has 2 ECB’s in the list 
>>> One for the EZASMI SELECT and one for the communication ECB
>>> 
>>> The one task that got dispatched has a number of ECB’s waiting 
>>> 
>>> Things is 1 out of 4 times the posted logic works 

Re: Modify ECB COMECBPT Intermittent response

[Joseph Reichman]

I think that was it 

From what I understand After getting the CIB address via extract 
I have to issue 2 QEDIT’s

The first with a BLOCK parameter to free the start CIB
The second to a limit on the number if CIB
L   RX,COMCIBPT
1st QEDIT ORIGIN=COMCIBPT,ORIGIN=(RX)
2nd QEDIT ORIGIN=COMCIBPT,CIBCTR=4
Thanks 


Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Dec 7, 2018, at 9:27 AM, Joseph Reichman  wrote:
> 
> Let me check 
> Thanks 
> 
> 
> 
>> On Dec 7, 2018, at 9:20 AM, Charles Mills  wrote:
>> 
>> Do you perhaps have a logic error relative to QEDIT? If you don't free the 
>> CIB you may never get another MODIFY.
>> 
>> Charles
>> 
>> -Original Message-
>> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
>> On Behalf Of Joseph Reichman
>> Sent: Thursday, December 6, 2018 10:48 AM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subject: Re: Modify ECB COMECBPT Intermittent response
>> 
>> It doesn’t have a wait bit there is only one task waiting on it 
>> The main task  has 2 ECB’s in the list 
>> One for the EZASMI SELECT and one for the communication ECB
>> 
>> The one task that got dispatched has a number of ECB’s waiting 
>> 
>> Things is 1 out of 4 times the posted logic works 

Re: Modify ECB COMECBPT Intermittent response

[Joseph Reichman]

Let me check 
Thanks 



> On Dec 7, 2018, at 9:20 AM, Charles Mills  wrote:
> 
> Do you perhaps have a logic error relative to QEDIT? If you don't free the 
> CIB you may never get another MODIFY.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Thursday, December 6, 2018 10:48 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Modify ECB COMECBPT Intermittent response
> 
> It doesn’t have a wait bit there is only one task waiting on it 
> The main task  has 2 ECB’s in the list 
> One for the EZASMI SELECT and one for the communication ECB
> 
> The one task that got dispatched has a number of ECB’s waiting 
> 
> Things is 1 out of 4 times the posted logic works