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
