David Crayford writes: >Do you have any "real" world experience with open source and >porting to z/OS?
Yes, some. Tony Harminc opines: >Sure, if all your application does is crunch numbers or manipulate >bytes. But if it has any interaction with the operating system such as >calling its services... Which (other) services? >referencing external names (dsnames and file names being only two of >many), There is no requirement on z/OS to support dataset names unless operating on datasets (VSAM files, PDSes, PDSEs, etc.) Which I've already covered in my statement. >dealing with operator services, etc. etc. etc., you will find it There is no requirement on z/OS for open source ported applications to "deal with" operator services. For example, there is no requirement on z/OS that applications produce SMF records. *Requirement*. Everything you're describing may be desirable, even highly desirable, but not REQUIRED. Now, I stipulate that there are many desirable capabilities. Operating on/with EBCDIC data is often useful. There are two ways to try to accomplish that goal: 1. Complain to and criticize each and every individual open source community for every open source product, that they must accept adding a laundry list of features to their mainline source code in order to exploit z/OS-unique and z/OS-desirable features. That approach doesn't seem to be working, does it? 2. As the Java community has, and IBM has (and continues to do), bolster the generalized runtime environments on z/OS so that more open source products can come to z/OS more easily and (optionally!) exploit z/OS without changes to the mainline source code (or with at least fewer changes). For example, if you want open source applications to be able to operate on/with EBCDIC data, how about a generic approach that works for all (or at least most) open source products? My /ebcdic path idea isn't necessarily best or even viable, but at least I'm trying. Might I suggest door #2? What would a "Common Transparent z/OS Services Environment" look like? I'm not excluding the possibility that IBM might implement *some* of that sort of stuff. IBM already is, e.g. z/OS 2.1's GNUish file I/O. For example, one radical (but probably viable) idea would be a userland GNU/Linux atop z/OS. Anybody interested in doing that? -------------------------------------------------------------------------------------------------------- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
