On Wed, 12 Nov 2008, Timothy Sipples wrote: > 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.
The idea is not bad, but is it the easiest way of doing it? BEGIN: somewhat lenghty explanation, you may skip it I hope my ignorance will be excused, as I am not a mainframer and I am reading this list in the hope of learning something new (or interesting, or something useful) - preferably by means of osmosis rather than time consuming and active effort (as I have to devote my time and energy to something else). Beyond this list, I am a Linux/x86 user. "User" is euphemism, and should be read as something like "installing, administering, compiling programs and kernels, sometimes tweaking things that do not want to work, solving hardware problems etc" - in other words, preparing heap of crap all by myself and after that, indeed, using it. More or less happily since 1994. Most often, the crap delivers what I expect, so this is a happy marriage. So, the usual thing on my Debian Linux is that programs here (they come in bundles called packages) are not always up to date because of "the policy" of making consecutive versions of Debian tested as much as possible, and this requires freezing things at some point. After release, admin is free to either use packages coming from the well-tested frozen set of packages (which may be not quite up to date because of the freeze), or replacing them with newer versions at their own responsibility. So, I have a "base os" with bunch of tools for compiling programs and/or creating packages. I would say, if something is called "unix" or similar, then such tools are a given and I would expect them to be on your z/UNIX too. IMHO, this ability to tweak things by oneself makes unix an OS, in contrast to some other OSes on PC, that are oriented around the ideas of pinball and minesweeper. END of: somewhat lenghty explanation Back to the problem - you do have the Unix (or unix-like) OS. You would like to run some Linux apps. At first, I thougth you meant closed-source ones. But later you have said "bash". Now, I may be an ignorant, but what prevents you from compiling newer bash by yourself? In case you really don't have tools for this on z/UNIX, I believe finding and configuring their free replacements is still easier than meddling with binary' execution. My quick googling for: +gcc +"z/os" +unix gave me something like this: http://mainframe.typepad.com/blog/2007/06/free_stuff_for_.html (this one signed by Timothy Sipples) http://www.cozx.com/~dpitts/gcc.html http://gccmvs.sourceforge.net/ (after short examination I think you will not want to use this one) Anyway, there seems to be some options for you. As of this "binary compatibility layer" - this is time consuming way. Lots of work before you will be able to consume fruits of it. I would probably go and try to adapt User Mode Linux or Co Linux (so I concur with Timothy Sipples on this). I think it is better to start with UML, because it runs as a process, so should be easier to port. CoLinux may be too strongly tied to Intel cpus (not sure about this, never looked inside it's source code). > To expand on those previous thoughts: > [...] > 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. If I understand the paragraph above, this has something to do with making a subsystem inside your z/UNIX - not in a LPAR (wow, I've used "LPAR" word for the first time in my life :-) ) sense, but by means of a subdirectory. There, one can put all the tools and their libraries and by changing environment variables LD_LIBRARY_PATH and PATH one can force the OS to load your bash (and other things) from this new directory. I mean, let's call it /sublinux :-). New bash will go into /sublinux/bin/ and if it needs any newer libraries, they will go into /sublinux/lib/ . You can automate running apps from this new subsystem a little with the following script: ---- cut here, save to newbash.sh ---- #!/bin/bash # /bin/bash above is the default system-wide old bash ### set new environment here: # fancy prompt PS1='\New.Bash (\D{%a, %Y-%m-%d} \t) =>:' # new environment for processes PATH=/sublinux/bin:${PATH} LD_LIBRARY_PATH=/sublinux/lib:${LD_LIBRARY_PATH} export PATH LD_LIBRARY_PATH PS1 # now 'bash' will be loaded from /sublinux/bin and all programs run # from new bash will be loaded from /sublinux/bin if they are there, # or from default system path otherwise. All bash scripts will use new # bash, etc. exec bash ---- cut here ---- Now all you need to switch your current terminal to using new set of tools is to invoke newbash.sh, it will run on top of your current shell. Fingers crossed - I have no experience with z/UNIX but I assume it follows some conventions, like using some environment variables mentioned above. However, building and maintaining your /sublinux by hand may be very tiring. You may want to examine some automatic package maintenance tools, like rpm or dpkg (this is my favourite one, of course, and it comes with additional tools dedicated for package building, but some people are complaining about its complexity). I've found this doc, but I have not had time to read it yet: http://documents.bmc.com/products/documents/14/98/41498/Output/090f44b18024ff13.htm Perhaps something of my remarks will be useful for you. Personally, I would prefer "sublinux" way over uml/colinux. Also, if you have a need to write long bash scripts, it is much better in my opinion to write them in some other scripting language. I mean, sh family was designed to be very simple glue connecting other programs. To use it efectively, one needs those programs too. A script rewritten in other language may become much simpler because of not having such needs. No need for separate calculator program, when one can do all calculations explicitly, for example. I don't like perl but it is quite good replacement. Python is even better. Spending time on learning it is fun and scripting in python is fun too (which means, "easy to write and works well"). So, after all thinking, you may come to the conclusion that porting one powerfull scripting language is better idea than porting uml or organising /sublinux. Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:[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
