In
<of5f4879d8.ef7c6ebe-on48257c14.0023d7b0-48257c14.00269...@sg.ibm.com>,
on 10/30/2013
at 03:01 PM, Timothy Sipples <[email protected]> said:
>If I could coach a little bit on the Perl "conversation" within
>the open source community, Perl's maintainers seem to be
>particularly hung up on EBCDIC support and not particularly
>interested in it (to be charitable).
The impression that I have is they're perfectly willing to accept the
code for EBCDIC support as long as it doesn't break anything; they're
not willing or able to write and test that code themselves. Do you
have any reason to believe that they would be unwilling to accept code
from, e.g., IBM?
>Well, OK -- but why impose that requirement when it doesn't exist
>in reality?
Why is Saturn the 3rd planet from the Sun? For many, the requirement
for EBCDIC support does exist in reality, and a language that does not
support it is out of the running.
>But why try to force EBCDIC into Perl "mainline" itself when z/OS doesn't
>require EBCDIC?
Again your question presupposes something contrary to fact; z/OS does
require EBCDIC. The fact that in some contexts it also supports other
character sets does not alter that.
>something like EBCDIC support should be quite easy to keep well
>segregated and generalized, via z/OS Unicode Services in particular.
No; the Devil is in the details.
>For example, if the path begins with: /ebcdic/...
Bletch! Tagging is a lot cleaner.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
