develooper Front page | perl.perl5.porters | Postings from September 2011


Thread Previous | Thread Next
Craig A. Berry
September 26, 2011 14:05
Message ID:
[once again adding perl-mvs to the CC list.  Going out of our way to
avoid contact with EBCDIC users is probably not the best way to figure
out what they actually do with Perl.]

On Mon, Sep 26, 2011 at 1:44 PM, Aristotle Pagaltzis <> wrote:
> * Karl Williamson <> [2011-09-26 19:10]:
>> I thought I had found an EBCDIC smoker a while ago; and the contact
>> person there said that he had successfully compiled and run Perl 5.12
>> (I believe) on his machine. I was very surprised at that, until it
>> came out that his shop, while using a platform that was natively
>> EBCDIC, was running everything on it in a UTF-8 locale. They had
>> abandoned EBCDIC because IBM had created good UTF-8 support, and there
>> were just too many outside programs they wanted to use that didn't run
>> on EBCDIC.
> Under those circumstances, I believe it plausible – though I have no
> means of ascertaining its likelihood – that ripping out the current
> EBCDIC support and consolidating all code to consistently assume Unicode
> and just Unicode, with the concomitant simplification, could well make
> it *easier* to make perl work on z/OS anew: a contemporary z/OS port of
> perl might be better off taking advantage of the UTF-8 support of that
> platform. In other words a modern z/OS perl port might differ totally
> from perl’s legacy z/OS support, which might therefore be not a starting
> point, but in fact an active hindrance to renewed porting efforts.

It's difficult to know without actual domain expertise, but I suspect
this is just wishful thinking.  The fact that z/OS now has Unicode
support doesn't mean any particular site can simply abandon EBCDIC
willy nilly at no cost.

A far more likely scenario would be someone with programs comprised of
millions of lines of COBOL or PL/I that are used to maintain a data
store in EBCDIC. At some point it became desirable to present some of
that data to the outside world, and Perl was chosen as the natural
swiss-army-chainsaw-interweb-duct-tape solution.  Sure, the data are
converted to ASCII somewhere along the way, and it's possible to
imagine re-architecting such a solution so that the conversion happens
before a UTF-8-based Perl sees it instead of after an EBCDIC-based
Perl sees it.

But it seems far more probable to me that Perl would have been chosen
specifically because it integrates into an environment where it sits
on the same side of the ASCII/EBCDIC divide as the existing code and
data and converting the data and/or code away from EBCDIC would be
prohibitively expensive.  Such conversions are possible (see for
example <>),
but that doesn't mean they are feasible in any given situation.

I think the use case for an EBCDIC-based Perl is clear enough.  The
question is whether any EBCDIC users can or will step up and maintain

> So the game score stands as follows:
> • The current EBCDIC support is not doing anyone any good

Not if they want a Perl later than 5.8.7.  I don't think we even know
how desirable that is.

> • Retaining it imposes a tax on new features


> • Even the very z/OS users it’s for could be better off without it

Seems unlikely, for reasons stated above.

> In addition, so far, the most recent version of perl any z/OS user has
> come forward to talk about is 5.12 – which is not going to be affected
> by the removal of anything in 5.16, not to mention is about to be EOLd.
> It would be a very nice feather in Perl’s cap to continue to run on the
> big iron at those Fortune 50 woodworks we just had people come out of,
> but I also notice there is no one both in a position to do the work and
> having offered to do so. So given the score card above, it seems as much
> as *unwise* to me to try and keep the half-dead platform support code
> around.

I agree that the current EBCDIC support is a zombie, for reasons best
explained by Nicholas.  It's not fully alive (Perl 5.10 and later may
or may not even compile) but it's undead enough to cause trouble.  It
needs either a decent burial or a full resurrection.  The latter can
only happen if EBCDIC users do the porting work or get IBM to do it
for them.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About