The MVS/380 effort was about compiling GCCMVS on MVS. He has concentrated on C/90, so may be out of date.
On Mon, Jul 8, 2024 at 5:08 PM Charles Mills <[email protected]> wrote: > > I wasn't sure what you meant. I think what you are asking is: > > Is there a fairly generic C library for MVS other than LE that provides a C > API to common MVS services? > > If so, I doubt it. But possibly ... > > There was an MVS C compiler in the pre-LE days. It was a port of one of the > common C compilers -- I am trying to remember the vendor. Lattice C -- I > think that's it. Then there was SAS C. We used both -- back before I knew C > -- at my old company in the roughly 1996-1998 timeframe. That's before LE, > right? What did they use for an MVS API? > > Also, "MVS" is a big tent. What specifically? ENQ/DEQ? WTO? Or what? Or by > "MVS" do you perhaps mean DFSMS? OPEN, CLOSE, GET, PUT, ... > > Do you have a basic C library? malloc(), printf(), etc.? What do they use as > an MVS interface? > > Charles > > On Wed, 3 Jul 2024 16:04:09 -0500, Paul Edwards <[email protected]> wrote: > > >There has been a recent development that means that I now > >have a C90-compliant compiler, assembler and linker that > >allows me to produce MVS load modules (in IEBCOPY unload) > >on basically any environment - ASCII or EBCDIC (I've only tested > >building on Windows and running on z/PDOS though). > > > >So here is what I do: > > > >gcc370 -Os -S -I. testmvs.c > >as370 -a=testmvs.lst -o testmvs.o testmvs.s > > > >gcc370 -Os -S -I. mvs.c > >as370 -a=mvs.lst -o mvs.o mvs.s > > > >as370 -a=llmvs.lst -o llmvs.o llmvs.asm > > > >pdld -e main --oformat mainframe -o testmvs.exe testmvs.o mvs.o llmvs.o > > > > > >The executables used above are available in the dos directory > >of the PDOS/386 hard disk image (pdos.zip) at pdos.org > > > >The assembler used is more-or-less standard HLASM, but the > >pseudo-ops are not, and nor are macros available. However, > >for my goal, that is not a problem as almost all assembler will > >be temporary and C-generated. Also note that the object code > >above is ELF - but again - temporary so I'm not concerned about > >it being non-MVS-standard. Note that pdld accepts standard > >object code also, and you can also have both forms of object > >code as input. Also note that the pdld author is likely to be > >willing to make small usability modifications if desired. > > > >And there are two different ways I would like my executables to run. > > > >One is to do an SVC, like SVC 35 to do a WTO. > > > >The other is for the application to detect at startup whether it was > >called from a PDOS-generic environment, and if so, when it is time > >to do an SVC - channeled into the __svc function - it instead does a > >callback. So real SVCs do not need to exist/be accessible. The > >PDOS-generic loader would probably do something like zap the > >first 4 bytes of the executable to be a pointer to a structure. > >Meaning the executables are limited to the ones that are built > >aware of this. For my use case that is fine, but some other > >mechanism could potentially be used. > > > >Normally my C programs have some startup assembler to create a > >stack, as seen here: > > > >https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvsstart.asm > > > >But I have omitted that in my test program, thus the OS needs to provide > >a stack, thus the test program at http://pdos.org/mftest.zip only works > >with z/PDOS available from pdos.org > > > >I have also omitted the PDOS-generic environment detection and use. > > > >Anyway, this is my question. > > > >I am wondering whether there is an existing C interface to MVS. There > >wasn't at the time of MVS 3.8J - not from IBM anyway - but there might > >have been some 3rd party vendor. Or maybe IBM now provides one > >that could be backdated to MVS 3.8J. > > > >It's unclear to me what the proper interface should be. I have experience > >in adding wrappers to MSDOS APIs, like this: > > > >unsigned int PosDisplayOutput(unsigned int ch) > >{ > > union REGS regsin; > > union REGS regsout; > > > > regsin.h.ah = 0x02; > > regsin.h.dl = ch; > > > > int86(0x21, ®sin, ®sout); > > > > return (regsout.h.al); > >} > > > >(in pos.c in the pdos/src) > > > > > >but the mainframe tends to only use a single register, and may > >require a different breakdown. Here is what I did just to prove > >that it works: > > > >#include "mvs.h" > > > >int wto(int len, int flags, char *msg) > >{ > > char buf[84]; > > regs regsin; > > regs regsout; > > > > *(short *)buf = len; > > *(short *)(buf + 2) = flags; > > if (len > 84) len = 84; > > if (len < 4) return (0); > > memcpy(buf + 4, msg, len - 4); > > regsin.r[1] = (int)buf; > > __svc(35, ®sin, ®sout); > > return (0); > >} > > > >Any suggestions/direction? > > > >Thanks. Paul. > > > > > > > >* Function __svc code > > L r7,0(,r1) > > L r8,4(,r1) > > L r0,0(,r8) > > L r1,4(,r8) > > L r15,60(,r8) > > EX r7, .LSVC1 > > B .LSVC2 > >.LSVC1: > > SVC 0 > >.LSVC2: > > > > > >#include <mvs.h> > > > >int main(void) > >{ > > wto(9, 0, "CHUMP"); > > return (0); > >} > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
