develooper Front page | perl.perl5.porters | Postings from February 2014

Re: EBCDIC support is on the chopping block

Thread Previous | Thread Next
Nicholas Clark
February 21, 2014 10:04
Re: EBCDIC support is on the chopping block
Message ID:
On Thu, Feb 20, 2014 at 05:29:21PM -0600, Craig A. Berry wrote:
> On Wed, Feb 6, 2013 at 5:31 PM, Ricardo Signes
> <> wrote:
> >
> > As was brought up about 18 months ago...
> >
> >
> >
> >
> > for z/OS, specifically EBCDIC support, is on the chopping block.  So
> > far, no dedicated resources, human or otherwise, have been provided.
> There aren't dedicated resources for any other platform as far as I
> can tell, so that's a bit of a double standard.  "Consistently
> available" might be a bit more reasonable.

Yes, that's a reasonable correction for the wording. The intent remains the
same, and and as you commented in another e-mail:

On Thu, Feb 20, 2014 at 05:35:40PM -0600, Craig A. Berry wrote:
> On Thu, Feb 20, 2014 at 12:57 PM, Brad Gilbert <> wrote:
> > Really all that is being asked is that someone compile Perl, and run some tests
> > on a regular basis. Which can, and should be automated.
> > With the promise to continue to do so for the foreseeable future.
> That would be a good start but it's going to take quite a bit more
> than that.  Someone with domain expertise or at least machine access
> would need to monitor the test results and submit patches for things
> that get broken.

The problem isn't z/OS itself. Another OS isn't a big deal, as perl builds
on platforms which none of the committers have access to. We know this
because we get reports back from people who are building on them, with minor
patches to fix up inadvertent breakage or portability issues.

The problem is that unlike every other platform, Perl on z/OS is using
EBCDIC, and UTF-EBCDIC. None of the commiters, and none of the other regular
contributors have any access to anything EBCDIC. So it's quite possible to
inadvertently totally break all EBCDIC systems, in a way which is quite
impossible to do for ASCII based systems, because if you're on an ASCII
based system you know about it. Which is bad.

And we have no feedback abut this. Which is worse.

An internally ASCII-based perl on z/OS would not have any of these problems.
But we don't have that. :-(

Nicholas Clark

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