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
