Re: C DLL Code from Assembler
Hi Tony, I'm in the process of rewriting GENCB for the z390 Emulator It's in use by CICS and many other things GENCB BLK=RPL,ACB=(R5),... It would be a serious bug if it didn't work I tried it and it works with MF=omitted, E and G An ST places the content of R5 into the ACE block Register notation is invalid with MF=L Melvyn Maltz. - Original Message - From: "Tony Harminc" To: Sent: Tuesday, July 02, 2019 8:54 PM Subject: Re: C DLL Code from Assembler On Tue, 2 Jul 2019 at 12:50, John McKown wrote: Wouldn't it be nice if IBM were to extend the GENCB macro to include BLK=DCB in addition to BLK=ACB, BLK=RPL, BLK=EXLST, and BLK=NIB? OTOH, does anyone actually use GENCB? My impression is that GENCB and friends were effectively deprecated long ago. We have them in some of our legacy VTAM code, and there are all kinds of annoyances and things that they don't do correctly and completely. (For example, a GENCB BLK=RPL,ACB=(Rn),OPTCD=... fails to store the supplied ACB address in the created RPL field RPLDACB.) It's a nice idea but a poor implementation. To say nothing about the need to bracket GENCB with ACONTROL FLAG(NOPAGE0) POP ACONTROL to avoid the HLASM complaint about no base register (because GENCB references the CVT with a L 15,16). That they haven't made that trivial fix in these many years says plenty. Tony H.
Re: C DLL Code from Assembler
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
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
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
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
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: C DLL Code from Assembler
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: C DLL Code from Assembler
https://en.wikipedia.org/wiki/Dynamic-link_library#Using_DLL_imports https://stackoverflow.com/questions/10429001/calling-a-dll-function-inside-a-c-program Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, July 2, 2019 2:24 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: C DLL Code from Assembler 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
Re: C DLL Code from Assembler
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 open to read to c
Re: C DLL Code from Assembler
Conceptually this is not difficult at all. I was until recently responsible for a large commercial product written in C++. I did all of the alpha unit testing in Visual Studio on Windows. It was not a "useful product" on Windows (because of differences in the environment external to my code) -- you could not have sold it as a commercial product for Windows -- but 95% of the code "worked" at least at the unit level. It all depends as I wrote below on the problem to be solved. Some business problems are very different technically on Windows. The product I describe processed SMF records. Windows does not report events using SMF records, so the business problem is very different, but all the bits and pieces of processing them work the same on Windows. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, July 2, 2019 1:20 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: C DLL Code from Assembler 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 wr
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 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. >>>
Re: C DLL Code from Assembler
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 "real" (LE) C.
Re: C DLL Code from Assembler
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 "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
On Tue, 2 Jul 2019 at 12:50, John McKown wrote: > Wouldn't it be nice if IBM were to extend the GENCB macro to include > BLK=DCB in addition to BLK=ACB, BLK=RPL, BLK=EXLST, and BLK=NIB? OTOH, does > anyone actually use GENCB? My impression is that GENCB and friends were effectively deprecated long ago. We have them in some of our legacy VTAM code, and there are all kinds of annoyances and things that they don't do correctly and completely. (For example, a GENCB BLK=RPL,ACB=(Rn),OPTCD=... fails to store the supplied ACB address in the created RPL field RPLDACB.) It's a nice idea but a poor implementation. To say nothing about the need to bracket GENCB with ACONTROL FLAG(NOPAGE0) POP ACONTROL to avoid the HLASM complaint about no base register (because GENCB references the CVT with a L 15,16). That they haven't made that trivial fix in these many years says plenty. Tony H.
Re: C DLL Code from Assembler
+1 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Tuesday, July 2, 2019 10:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: C DLL Code from Assembler No. No one does, and no one ever has. I tried them once, looked at the expansions, had a good laugh, and never did again. sas On Tue, Jul 2, 2019 at 12:50 PM John McKown wrote: > On Tue, Jul 2, 2019 at 11:31 AM 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. > > > > Wouldn't it be nice if IBM were to extend the GENCB macro to include > BLK=DCB in addition to BLK=ACB, BLK=RPL, BLK=EXLST, and BLK=NIB? OTOH, does > anyone actually use GENCB? > > > > > > > Charles > > > -- > Money is the root of all evil. > Evil is the root of all money. > With that in mind, money is made by the government ... > > > Maranatha! <>< > John McKown > -- sas
Re: C DLL Code from Assembler
No. No one does, and no one ever has. I tried them once, looked at the expansions, had a good laugh, and never did again. sas On Tue, Jul 2, 2019 at 12:50 PM John McKown wrote: > On Tue, Jul 2, 2019 at 11:31 AM 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. > > > > Wouldn't it be nice if IBM were to extend the GENCB macro to include > BLK=DCB in addition to BLK=ACB, BLK=RPL, BLK=EXLST, and BLK=NIB? OTOH, does > anyone actually use GENCB? > > > > > > > Charles > > > -- > Money is the root of all evil. > Evil is the root of all money. > With that in mind, money is made by the government ... > > > Maranatha! <>< > John McKown > -- sas
Re: C DLL Code from Assembler
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
On Tue, Jul 2, 2019 at 11:31 AM 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. > Wouldn't it be nice if IBM were to extend the GENCB macro to include BLK=DCB in addition to BLK=ACB, BLK=RPL, BLK=EXLST, and BLK=NIB? OTOH, does anyone actually use GENCB? > > Charles > -- Money is the root of all evil. Evil is the root of all money. With that in mind, money is made by the government ... Maranatha! <>< John McKown
Re: C DLL Code from Assembler
@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
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
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
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
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
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
