Dan Poirier wrote:
Greg Stein <gst...@gmail.com> writes:
Understood. But if you're writing new code (for APR 2.x), then why
wouldn't you develop the codebase in Unicode? "Link with old
libraries" might be an answer, though I'd say "it is outside the scope
of APR to interact with that old library".
Frankly, it would be nice if the APR 2.x API was pure Unicode charset,
encoded as UTF-8 across the board.
I'm not disputing that EBCDIC is still in use (as you eminently point
out). Just that I fail to see it has a strict, useful requirement for
APR 2.x.
Frankly, internal Unicode would be great. Just so input and output
still support EBCDIC, since people still do use it. (Maybe even just
input - does anyone actually serve web pages in EBCDIC?)
Well, I was just going to lurk, but I believe the answer
to this question is No. The z/OS servers convert EBCDIC
strings to UTF-8 by default. I don't think many (any?)
browsers support EBCDIC.
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Check out the Trainer's Friend Store to purchase z/OS <==
==> application developer toolkits. Sample code in four <==
==> programming languages, JCL to Assemble or compile, <==
==> bind and test. <==
==> http://www.trainersfriend.com/TTFStore/index.html <==
