Tim, You make some excellent points... On Wed, Nov 12, 2008 at 12:43 AM, Timothy Sipples <[EMAIL PROTECTED]> wrote: > > 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.
LSB is a nice idea, but currently its implementation is in shambles IMO. I can say this because we actually ship an LSB certified application, but as you can see currently only a handful of applications that have signed up: https://www.linuxfoundation.org/lsb-cert/productdir.php?by_prod > > 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. Very nice idea. UML under z/OS would be cool. > > 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.) > This is similar to what I proposed, only using Linux virtual machine guests. Your idea of using a UML approach seems better. BTW: If you want to interact between a z/OS job step and a zLinux guest over hiper-sockets, you can do it now: //STEP1 EXEC PROC=COZPROC, // ARGS='[EMAIL PROTECTED]' //STDIN DD * # This shell script runs on zLinux fromdsn -l rdw -k //DD:INPUT \ | gpg -r key-1 --batch --output=- --encrypt=- \ | todsn -b //DD:OUTPUT /* //INPUT DD DISP=SHR,DSN=KIRK.CLEARTEXT.DATA //OUTPUT DD DSN=KIRK.ENCRYPT,DISP=(NEW,PASS), // SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=U,BLKSIZE=4096) > Interesting project! > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: [EMAIL PROTECTED] P.S: A joke once told to me by an old IBMer : - "programmers" write code - "architects" talk about writing code - "methodologists" talk about talking about writing code ---------------------------------------------------------------------- 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
