MVS, or z/OS as IBM currently call it, has a built-in Unix environment known as USS (for Unix System Services). It first came out in 1993 as MVS OpenEdition, and provides the POSIX-y sort of experience you all know and love, only running as a subsystem of the main OS. (I intend to add a page going further into this stuff at some point. Progress is... not quite 'glacial' [1]) To give you an idea, here's a 'screenshot' (t530 is my laptop): t530$ ssh zos23 LEE@S0W1:~$ uname -a OS/390 S0W1 26.00 04 1090 LEE@S0W1:~$ ls -la total 86208 drwxr-xr-x 7 LEE SYS1 8192 Jan 2 15:05 . drwxr-xr-x 23 OMVSKERN SYS1 16384 Dec 13 17:48 .. -rw------- 1 LEE SYS1 40061 Jan 4 01:48 .bash_history -rw-r--r-- 1 LEE SYS1 3552 Dec 20 15:57 .bashrc -rw-rw-rw- 1 LEE SYS1 71 Dec 14 13:22 .gitconfig -rw-r--r-- 1 LEE SYS1 852 Dec 19 14:44 .profile -rw------- 1 LEE SYS1 3790 Dec 14 12:22 .sh_history drwx------ 2 LEE SYS1 8192 Dec 14 19:54 .ssh -rw------- 1 LEE SYS1 13187 Dec 20 16:37 .tramp_history drwxr-xr-x 2 LEE SYS1 8192 Dec 18 22:46 ctest drwxr-xr-x 15 LEE SYS1 8192 Jan 2 17:47 dev -rw-r--r-- 1 LEE SYS1 43023346 Jan 2 15:06 git-2.14.4_b11.190917.tar.gz -rw-r--r-- 1 LEE SYS1 913602 Dec 15 11:31 ispfinst.exe drwxr-xr-x 2 LEE SYS1 8192 Dec 17 12:11 xmi drwxr-xr-x 6 LEE SYS1 8192 Dec 14 12:59 zigi LEE@S0W1:~$ 'OS/390' in the uname output is a bit of a hangover from the 31-bit days. This is running on z/OS 2.3 (latest version is 2.4, but that isn't installed on the machine I have access to yet). Commands can be sent to the 'MVS side' via the 'tso' command: LEE@S0W1:~$ tso "listcat level('lee.zigi')" listcat level('lee.zigi') NONVSAM ------- LEE.ZIGI.V1R3.EXEC IN-CAT --- USERCAT.STAFF NONVSAM ------- LEE.ZIGI.V1R3.GPLLIC IN-CAT --- USERCAT.STAFF NONVSAM ------- LEE.ZIGI.V1R3.PANELS IN-CAT --- USERCAT.STAFF NONVSAM ------- LEE.ZIGI.V1R3.README IN-CAT --- USERCAT.STAFF LEE@S0W1:~$ Things like 'cp' etc. can also talk to both sides of the OS eg. you can cp between USS files/directories and MVS datasets. (Zigi is an ISPF front-end to 'git' [2]) So, for the last couple of weeks or so, I've been attempting to get various well-known open-source packages compiled for USS. Stuff I've got so far includes a handful of Gnu utilities (make, m4, etc) along with some other miscellany (perl, lua, that sort of thing). Now, some OSS packages include MVS ports (usually OS type 'os390' or something), which is great, because those usually build with very little manual labour. The ones that don't however, generally have one or more of the following problems: - Compiler assumptions There's an ancient port of GCC/glibc here [3], but I haven't used it. It's a fairly old compiler, built on a fairly old OS (z/OS 1.1). While the backwards-compatibility in MVS is AFAIK unparalleled by any other OS, I wonder if it's the same for USS? Plus, software detecting gcc at build time is probably going to expect a much newer version than this. Also, that 'This is NOT a production-quality compiler...' bit is somewhat unnerving :) The upshot of all this is that I'm using the IBM xlc compiler, which is nice, but means that a large number of unixy compiler flags will need to be massaged/changed/removed in order for the IBM compiler to even start looking at your source. How does this compare to your favourite 'gcc' command-line? xlc -D_ALL_SOURCE -D_EXT -D_ISOC99_SOURCE -D_OPEN_MSGQ_EXT -D_OPEN_SYS \ -D_POSIX_SOURCE -D_UNIX03_SOURCE -D_UNIX03_THREADS -D_XOPEN_SOURCE=600 \ -D_XOPEN_SOURCE_EXTENDED \ -qlanglvl=extended:extc89:extc99 -qfloat=ieee -qlongname \ -qhaltonmsg=3296 -qxplink -qdll Then there's the whole '-L' thing, or the completely different flag format if you're calling the compiler as cc or c89... yeah, fun. - What's Unix? Anyone who's ever done any porting work knows this pain. It's like going back in time to the Unix wars again - hardly anyone includes 'os390' code, so you're mostly on your own trying to get something to compile. #ifdef __MVS__ has become a close friend. Any 'configure' scripts supplied can be extremely hit-and-miss. - EBCDIC Anything doing text processing probably needs to be pored over to check for ASCII-isms (assumptions about sorting, newline characters and so on.). Good test suites are a godsend here - any package with an ASCII-centric view will usually generate a whole bunch of test failures. Anyway, that's what I've been doing recently. My Gnu grep 3.3 tests finished while I was writing this, looks like I've got some work to do: SKIP: z-anchor-newline ======================================================================== Testsuite summary for GNU grep 3.3 ======================================================================== # TOTAL: 110 # PASS: 42 # SKIP: 56 # XFAIL: 1 # FAIL: 11 # XPASS: 0 # ERROR: 0 ======================================================================== See tests/test-suite.log Please report to bug-grep@gnu.org ======================================================================== [1] gopher://republic.circumlunar.space/1/~leeb/mf/mvs [2] https://github.com/wizardofzos/zigi [3] https://www.cozx.com/dpitts/gcc.html