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
<[email protected]> 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 <[email protected]> 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
><[email protected]> 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 <[email protected]> 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:[email protected]]
>> On Behalf Of Joseph Reichman
>> Sent: Monday, July 1, 2019 2:04 PM
>> To: [email protected]
>> 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 <[email protected]> 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:[email protected]]
>>> On Behalf Of Joseph Reichman
>>> Sent: Monday, July 1, 2019 1:25 PM
>>> To: [email protected]
>>> 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
