On Mon, 8 Jul 2024 17:08:15 -0500, Charles Mills <[email protected]> wrote:
>I wasn't sure what you meant. I think what you are asking is: Hi Charles (and others). Thanks for your reply and sorry for the delay. During the delay I have managed to prove the concept that PDOS-generic works on the mainframe too. So there is now a z/PDOS-generic (search for that string at https://pdos.org to get zpg.zip). This is designed to be a clone of MSDOS, same as PDOS/86 and PDOS/386, but now ported to the mainframe (the same as if Microsoft had chosen to do that - but presumably didn't because of lack of market need or whatever). Note that that includes a FAT file system (including FAT32), in EBCDIC. It should support EBCDIC ANSI terminals as well, but I've only tested 3215 on Hercules because I've previously tested EBCDIC ANSI terminals on real hardware, so that concept is already proven - I'm onto this new one. >Is there a fairly generic C library for MVS other than LE that > provides a C API to common MVS services? Yes - or even LE itself if it is document/well understood (I'm after design guidance/suggestions here). >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? I guess I have conflated two different things. 1. A dynamic C library that resides outside the executable (similar to msvcrt.dll for Windows). 2. A dynamic or even static MVS-interface library that may or may not be in the executable (similar to kernel32.dll for Windows). Although almost all my programs are C90-compliant, so I only care about number 1 (ie my executables only have a dependency on msvcrt.dll), there are some things, like zip, which need to traverse directories, so I need something more. Interestingly, the "something more" I chose for directory traversal is the MSDOS API with C wrappers on it, rather than Windows. So my zip program doesn't run on Windows, only PDOS/386. So there may be similar things for MVS, like issuing a WTO, perhaps with specific routing codes, that are not covered by LE. Note that in everything I am doing, I am not directly using z/OS, I am producing a clone, or in sometimes a completely alien alternative to z/OS. But at least with z/PDOS (not generic), I have the ability to produce executables that run under both z/PDOS and z/OS - without needing alternate code paths or other kludges. In the case of generic, it currently only runs z/PDOS-generic apps (similar to UEFI apps with a callback facility - similar to Amiga OS too). So I am looking into the possibility of upgrading that to support other APIs *as well*. Note that I have done this in other environments too - PDOS/386 supports a 32-bit MSDOS API, Win32, OS/2, Linux and PDOS-generic executables. The additional APIs were added with minimal code since I am only trying to support C90 applications, so when an OS/2 program calls fopen, which means the executable has a call to DosOpen in it, and that is where PDOS/386 regains control (since it satisfies the doscalls.dll references), and then turns around and converts it straight back into an fopen using the internal C library. Note that some of the things I have done - no protection whatsoever - are not really designed to be commercially viable - it is more to create a starter system so that something else can be written. But if you're willing to live with the limitations, you can indeed do useful things - as you could on MSDOS too - for many years. And the fact that IBM won't sell a z/OS license to your emulated environment - at least not for a commercial workload - is not a problem if your commercial workload is willing to live with those limitations (or some modification of that). > Also, "MVS" is a big tent. What specifically? ENQ/DEQ? WTO? Yes, good point. Ultimately I would expect a front-end to each SVC, plus the ability to insert one or two arbitrary assembler routines for callback purposes, so that from the high level C you can satisfy the requirements of the SVC so that you can get the functionality provided by that SVC. The assembler callback routines/plugins would call C routines so that the C code can regain control when the SVC (or system routine like you see with READ vs OPEN) invokes it (like during EOF) so that you can do the logic in C. I'm not expecting to be able to use assembler macros - this is an alternative to that. > Or what? Or by "MVS" do you perhaps mean DFSMS? > OPEN, CLOSE, GET, PUT, ... Initially, my main interest is just in satisfying the requirements of C90, so the above are almost everything. But they aren't everything even for C90 - if my executable detects that it is in a TSO environment, I expect PUTLINE to be called - and that's what I'm already doing in my C library PDPCLIB. >Do you have a basic C library? malloc(), printf(), etc.? Yes - I have all of that - and incidentally, nothing at all more than that. No extensions at all unless you want to quibble. > What do they use as an MVS interface? The C library is mostly written in C, but when it needs to interact with MVS (and I have a similar thing for CMS and VSE), it calls an assembler routine to do that, using the documented MVS interface. Which has served me fine up until now, but I'm looking to change that so that there is minimal logic in assembler. You can see the assembler interface here: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm That has been lovingly handcrafted over years by Gerhard Postpischil mainly, but others have also been involved (I wrote the original bare bones as proof of concept). So I'm basically looking to reverse-engineer that code and rewrite it in C. But by doing so I would be creating a different interface to the same MVS API. IBM didn't create/document such an interface (that I know of), but I will. The situation was the same with MSDOS. Interestingly, in the MSDOS 4.0 source code, you can see that they (Microsoft or IBM - not sure) did actually create a C interface to MSDOS - indeed - it's very similar to OS/2 - but I don't remember them ever publishing that. That's one thing I want to do. The other thing I want to do - or maybe do - is convert my C library - currently statically-linked into all my executables - into a dynamic DLL or whatever - whatever LE does - or some other vendor like SAS that was mentioned - maybe. Why would I do that when LE already exists? Answer - MVS 3.8J doesn't have LE, so my C library would create a mini LE. And then I could write programs that target the mini-LE - and they would be smaller, and also, when those executables are run under z/OS, they would not only work, but they would be making use of the more professional IBM version of the C library. And not just MVS 3.8J. The C programs should also be able to run under both z/PDOS and z/PDOS-generic if I add suitable code. I already added a small amount of code to the PDOS-generic environment to support the Amiga OS as proof of concept. But that was actually documented. I'm not sure LE is even documented, which is why I would potentially be using someone else's "MVS DLL" (like SAS/C) or whatever. It's unlikely, but possible, that there is some technical show-stopper that prevents me from turning PDPCLIB into a mini DLL for MVS compatible with SAS/C or IBM. ie I may be missing a concept. So I'm still after guidance/suggestions. And not just for the C library - but also z/PDOS-generic (ie MSDOS on the mainframe). I made a fresh start with that, so I need to copy code over from PDOS/386 to PDOS-generic, and now that the mainframe is in place, I basically have a regression-test environment so that any changes to my MSDOS mini-clone are also available on the mainframe. It is expected to always be like that. This OS should not outrun the mainframe. That's a big reason why PDOS-generic isn't as sophisticated as PDOS/386 - even on the 386 environment - I held back development until I could be sure that the mainframe wasn't left behind. For some definition of "behind", anyway. ie my own code. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
