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 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> 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
<reichman...@gmail.com> 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 <jperr...@pacbell.net> 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
><reichman...@gmail.com> 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 <charl...@mcn.org> 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 <charl...@mcn.org> 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
