John McKown writes: >I think I understand where you're coming from. I'm glad somebody does. :-)
>But this is, in and of itself, a "nasty EBCDIC" problem >because code on z/OS generally _assumes_ that character >data is encoded in CP-037 (historic batch?), or maybe >IBM-1047 (UNIX). Yes, you're describing interoperations with EBCDIC-encoded data (and other programs that operate on such). Often nice to have no matter where Program B runs if Program A operates on EBCDIC. Look, I think too many people have this point exactly backwards, and it's an important point. (And not the first time we've discussed this.) You can bring a program that operates on ASCII or Unicode (or McKowncode) to z/OS without lifting a finger with respect to EBCDIC support. Zip, zero, nada. That's common and getting more common. Let's call that a "Phase 1" port, and you might very well stop there. Now, if it happens, in Phase 2 (or Phase 8), you may decide that it'd be nice if your Program B interoperates with the EBCDIC-encoded data Program A stores. You have two basic options: 1. Program B could run somewhere else, and you'd have to figure out how to deal with EBCDIC-encoded data over the wire. (Maybe the operating system or middleware help you do that.) 2. Program B runs on z/OS, and in addition to all the wire options you have other options -- the world is your EBCDIC oyster. Which is better? I'd vote for Option #2. There is/are more flexibility and more opportunities for providing interoperability as you wish. BUT that EBCDIC interoperability is NOT a prerequisite to run on z/OS. Interoperability is ONLY a prerequisite if there is a requirement for interoperability. That requirement is a completely separate matter, if it even exists, when it exists. Very, very important point here, worth practicing. Insist on EBCDIC interoperability in Phase 1 where no such interoperability exists today and, well, you're going to have fewer programs on z/OS and have less ability to make interoperability happen well. Actually, you said it very well earlier, John, in your Java example: you just move a Java program over, as-is, compiled, and it runs, unmodified. There's nothing you *have* to do unless you wish, for other reasons. The same is true with, for example, C. Compile your C program in ASCII in z/OS UNIX, run it in ASCII -- no problem. Works great. EBCDIC interoperability isn't the only example of an attribute that is nice to have but not a prerequisite to run an application on z/OS. Here are a couple other examples: support for SMP/E installation and maintenance, SMF record generation. I suppose some people might stomp their feet and throw a temper tantrum, insisting on these two (and perhaps other) attributes before they'll let an application run on "their" z/OS, but that's their hangup, not z/OS's. So let's be very careful here to stick to the facts, OK? Fact: EBCDIC support is NOT a prerequisite to bring a program to z/OS and run it there. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
