It's not a crazy thought. At least I don't think so, for what it's worth. The idea came up in passing recently when a student working on a final project asked for some ideas. One of my suggestions was exactly along these lines.
To expand on those previous thoughts: 1. There's no EBCDIC requirement here. Some people like to have it (for log files, as an example), and it is nice to have as an operational convenience, but it's not a hard requirement. z/OS is quite happy supporting ASCII and Unicode applications and databases. So you could probably skip EBCDIC completely, at least in initial efforts. 2. There's something called the Linux Standard Base (LSB) which would provide the common application environment that most people care about when they say "Linux." So you could create (and maintain) an LSB for z/OS, borrowing copiously from UNIX System Services. 3. Alternatively, there are whole distributions of Linux that run as applications within a parent operating system -- and which don't use virtual machine products to do it. Take a look at Cooperative Linux and user-mode Linux (UML) as notable examples. Cooperative Linux looks like a good starting point. I believe the Cooperative Linux code is already committed to and maintained in the mainline i386 Linux kernel source code. So you'd have to enhance Cooperative Linux code such that it could also be incorporated into the s390x kernel stream, and so that it would invoke z/OS services instead of Microsoft Windows services. That would probably be the cleanest approach from a code maintenance point of view. You might have a little complexity given the fact z/OS (currently; it's an architectural decision not limitation) only allows code execution out of the first 2 GB of a 64-bit address space. I suspect you would need to tweak the s390x kernel so that it's aware of that and shuffles execution down into the 2 GB zone, or just use a simple brute force method of limiting the z/OS Linux address space to a maximum of 2 GB in an initial effort. (From Linux's perspective it would think it's running on a 2 GB machine, or less.) I don't think I'd bother with the 31-bit s390 kernel branch at this point in history -- I think I'd concentrate on the 64-bit s390x branch since that'll get the most attention. And then eventually you might have something like "BPXLINUX" (analogous to BPXBATCH) which allows z/OS to interact with a Linux address space in certain fun ways, but that'd be in the future no doubt. Initially it'd just be a very isolated instance of Linux relying on z/OS services instead of hardware (or virtualized hardware) services for I/O, memory, and CPU. (Mapping I/O is most of the effort.) Interesting project! - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
