As long as the program accepts the data as valid and doesn't check it for valid ASCII characters, it should work for any character set. Let the operating system determine if it is a valid data set name, path, etc.
On Fri, Nov 1, 2013 at 10:51 AM, Tony Harminc <t...@harminc.net> wrote: > On 1 November 2013 02:47, Timothy Sipples <sipp...@sg.ibm.com> wrote: >> Tony Harminc opines: > [with respect to the need to use EBCDIC] >>>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? > > ENQ/DEQ. WTO/WTOR/QEDIT and friends. OPEN/CLOSE. TPUT/TGET. Many of > the UNIX callable services. There are many more. Some of the services > "merely" use EBCDIC constants or values in their invocations; others > actually deal with EBCDIC data. > >> 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. > > So my statement you quoted above pretty much covers it. If you are > happy for your app to run isolated, you are fine. If you want to talk > to the outside world, you need to support EBCDIC to at least some > degree. If what you have is a callable subroutine that manipulates > data and returns a result, yes of course the caller can do the > necessary translations on input and output. > >> *Requirement*. Everything you're describing may be desirable, even highly >> desirable, but not REQUIRED. > > Oh come on. A program is not REQUIRED to do anything beyond its > specifications, and those can be as minimal as you like. I will > stipulate that IEFBR14 will run fine in ASCII, EBCDIC, or even UTF-8. > What do you accomplish by making this point? > >> 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? > > A strange straw man to set up. I'm not aware of this complaining and > criticizing you speak of. Can you give an example of such a laundry > list? What I hear, and have contributed to, is the notion that people > should design and write code in a portable manner. This was once > considered evident "goodness" among almost all programmers, but the > notion has faded with respect to non-ASCII characters sets, whereas > e.g. portability wrt endianness hasn't. If you write non portable > stuff like > If "A" <= char <= "Z" then char_is_uc_alpha = TRUE > then you will have trouble running on any non-ASCII system. But this, > and worse, continues to this day. > > Quite evidently this has happened because while there are many > prominent platforms of both big and little endian pursuasion, there > are approximately five current EBCDIC OSs in existence running on two > hardware platforms, and most people know nothing about any of them. > >> 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). > > There's nothing wrong with this, certainly. But I see little to no > connection with your earlier point. > >> 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. > > This addresses an already-addressed problem, arguably in a worse way, > and it's the narrow problem of UNIXy 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? > > Perhaps, but it's hard to see the business case when zLinux and z/OS > UNIX already exist. And it certainly won't be IBM distributing it if > it's GPL licensed, which any GNU/Linux-based product would be. > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
