This is...interesting, but what is the goal? Or is it just an interest project? (Nothing wrong with that!)
Another "interest project": Way back in 2000, Adam Thornton fired up Linux under VM/ESA on a P/390. In Linux, he ran Bochs. In Bochs, he ran Windows. In Windows, he ran Exchange. Well, maybe "ran" isn't the right word: more like "crawled". But it DID come up. Eventually. On modern hardware, might even be tolerable! -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Paul Edwards Sent: Tuesday, August 5, 2025 3:53 PM To: [email protected] Subject: z/OS PCDOS If MSDOS/PCDOS had been ported to the mainframe (or any other CPU - even the 80386), something would have had to be changed, as you can't do an 8086 INT 21H to request DOS services. With that in mind, z/PDOS-generic is my rendition, which I have previously announced. This time, it can run under MVS: COPY INDD=((I1,R)),OUTDD=I2 IEB167I FOLLOWING MEMBER(S) LOADED FROM INPUT DATA SET REFERENCED BY I1 - IEB154I BIOS HAS BEEN SUCCESSFULLY LOADED IEB144I THERE ARE 0000287 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY I2 IEB149I THERE ARE 0000019 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY IEB147I END OF JOB -00 WAS HIGHEST SEVERITY CODE ^Lcopying from file dd:in, mode binary to file dd:out, mode binary 9564 bytes copied ^Lcopying from file dd:in, mode text to file dd:out, mode text 123 bytes copied ^L bios starting enter command, exit to exit about to execute program with entry point 02019408 welcome to PDOS-generic running as dd:pdos before printing parm argv1 is -c about to open disk done open lba is 1f8 fat type is opening dd:config shell name is :dd:pcomm about to call app at address 024DF8B0 welcome to pcomm type help for help enter a command d a t e Tue Aug 5 19:06:58 2025 enter a command d i r PDOS TEST TXT COMMAND EXE CONFIG SYS ád DEVEL BIOS EXE PDOS EXE TEST2 TXT XXX TXT TEST C TEST S át TEMP ZIP DOS To some extent it is "proof of concept", but we have a competent engineer (Dat Nguyen) from Vietnam who is expected to refine this in due course. There was one issue, which Dat has been working on for months (a large part of which was training). https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/stdio.c#l1743 /* this done_first variable is a workaround for what is presumed to be a bug in mvssupa.asm The first time a write is done, the read buffer should be overwritten from the beginning. But all subsequent writes require the first 4 bytes to be skipped. We need someone to look at the mvssupa.asm. Gerhard Postpischil wrote the relevant mvssupa.asm code, but he died years ago */ Is anyone interested in looking at the S/370 assembler here: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm You can obtain z/OS PCDOS from https://pdos.org (second occurrence of PCDOS) There is expected to be a z/OS Windows in due course, that allows you to write minimal programs using msvcrt.dll. I have already demonstrated that on the 68000. Another development since the zpg announcement is that z/PDOS-generic can now (effectively) drive a PC serial port so it can run a BBS (pdpbbs.exe) or dial one (devil.exe). Since it runs under an emulator, it is down to what the emulator can provide. In my case, that is mfemul.exe, and that runs under Windows, which means the mainframe can run the BBS under real Windows. I also produce a Windows mini-clone, which uses UEFI, and I have asked Dat to work on enabling serial port there too, which would in turn allow Virtualbox on a Mac M1 to run a mainframe BBS. Since the mainframe is being emulated either way, you can run it on a Mac. Note that with a second OSA/ICC tunneling through a Windows/Linux box with a real RS232 port, you should be able to attach a real traditional modem to a mainframe, depending on the definition of "attach". Also note that I have only demonstrated z/OS PCDOS running in batch, but it should run under TSO too. If you had a 3270 emulator that was able to switch to an EBCDIC version of ANSI X3.64, you should be able to run microemacs under TSO this way. There should probably be some standard way of the software signaling to the terminal emulator that it is switching between 3270 and EBCDIC ANSI. One other plan afoot (the groundwork has already been prepared) is to create an EBCDIC version of x86 Windows. This should allow certain mainframe data (that behaves using the PDPCLIB rules) to be offloaded to a PC and then certain C90 applications could do things like quickly searching a large file, not under emulation, and offloading work from the mainframe. Another thing is that you can produce ASCII Windows executables from the mainframe, as gccwin now works there. You can produce EBCDIC Windows executables too, but I haven't yet published an OS to run them. That's all I can think of at the moment. BFN. Paul. ---------------------------------------------------------------------- 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
