David 

I never got to the point of debugging with LE
As amode 64 C could not be debugged by debug tool I needed zos explorer 

With Metal the fact that syslin from the compiler is HLASM 

I was able to use test 

The cbttape has an LG command to display 64 bit registers and I can use Mark 
Zelden Rexxmem under TEST to display the 64 bit storage 

Writing your own I/O is a lot easier as when the subroutine gets control you 
just have to adjust the nab in entry and exit 

Thanks 








> On Nov 18, 2019, at 4:44 AM, David Crayford <[email protected]> wrote:
> 
> IIRC, you LE woes were not that LE "has problems" but more to do with the 
> fact that you could not get it to work :)
> 
> You can see how to do Metal/C IO here 
> https://github.com/zowe/zowe-common-c/blob/master/c/qsam.c. It's non-trivial! 
> I would suggest you were better off sticking with LE and persevering.
> I fear you have a heavy lift on your hands. I use both LE and Metal/C and I 
> would always opt for LE unless I was writing systems level code.
> 
> Of course, you can use zowe-common-c in your project which is written by 
> Metal/C experts.
> 
>> On 2019-11-18 3:39 AM, Joe Reichman wrote:
>> Charles
>> 
>> As an aside LE has too many problems I am using Metal I like the flexibility 
>> it has no I/O routines so I am using my own thus ran into the problem seem 
>> like read can run in 31 or 24
>> Seems LIKE SF64 only works for extended datasets
>> 
>> 
>> Thanks
>> -----Original Message-----
>> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
>> Charles Mills
>> Sent: Sunday, November 17, 2019 2:09 PM
>> To: [email protected]
>> Subject: Re: In what context/amode BSAM/BPAM READ with SF64
>> 
>> And for those exits that must be RMODE 24 all you really need is a little 
>> stub in BTL storage that upgrades its AMODE and branches to the real exit 
>> logic. The advantage is that you do not need a "real" AMODE 24 load module; 
>> you get just GETMAIN the BTL storage and move a few bytes of code into it.
>> 
>> Charles
>> 
>> 
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[email protected]] On 
>> Behalf Of Greg Price
>> Sent: Saturday, November 16, 2019 11:03 PM
>> To: [email protected]
>> Subject: Re: In what context/amode BSAM/BPAM READ with SF64
>> 
>>> On 2019-11-17 5:40 PM, Joseph Reichman wrote:
>>> I  normally do all I/O in amode 24 because of the EODAD of AL3 the
>>> open having an AL3 for the  DCB
>> Unless you have an old ESA or even older XA system, there's no need to do 
>> I/O in amode24 these days.  Just use amode31.
>> 
>> The AL3 pointers will restrict you to rmode24, but that's a different story.
>> 
>> If the only DCB exits you use are EODAD and/or SYNAD, and you want to go
>> rmode31 (or rmodeany if you prefer) then you can supply their 4-byte address 
>> in the DCBE macro.  But you do not need 4-byte pointers to them to use 
>> amode31.
>> 
>> About the only amode24 code for z/OS I write these days is for exits where 
>> only amode24 is supported.  DCB exits pointed to by DCBEXLST may be in this 
>> boat, as are the SYSIN and SYSPRINT (and other DD ??) exits used for 
>> supplying data to and consuming data from calls to the IDCAMS program.
>> 
>> Sometimes in rmode31 programs I GETMAIN BTL storage and load the code for 
>> DCB exits, but this technique is not required for EODAD and SYNAD exits due 
>> to their DCBE support.
>> 
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email 
>> to [email protected] with the message: INFO IBM-MAIN
>> 
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to [email protected] with the message: INFO IBM-MAIN
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to