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

Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT ina future release of Perl

Thread Previous | Thread Next
Karl Williamson
September 30, 2011 12:06
Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT ina future release of Perl
Message ID:
On 09/30/2011 05:39 AM, Dean, Sandy wrote:
> Here is the question I asked IBM:
> What is IBM's stance on supporting perl from this point
> forward? I am a heavy user of perl in the USS environment, and would
> need to redesign my applications if perl were to go unsupported.
> The open source group currently supporting perl on z/os is unable to
> continue because as things break (which they have), they have no
> platform on which to test, and no z/os developers who have the time to
> step up to the task.
> It is looking like IBM will need to officially support this product on
> USS or it is going to die a painful death.
> Please let me know your thoughts.
> Here is their response:
> IBM will continue to support the Ported Tools version of Perl for the
> forseeable future. It's separate from the open source code base.
>                                                                         .
> If and when the decision is made to support a newer version of Perl, IBM
> will tackle the EBCDIC aspects.

It is my understanding that more modern Perls will compile and run when 
the locale is utf8.  We also have Encode available to translate EBCDIC 
data to Unicode on input, and back on output.

It's quite likely that the current EBCDIC bugs have an easy solution. 
I've already figured out a trivial fix for the cases I know about where 
there are hard-coded UTF-8 vs UTF-EBCDIC string constants.

(I also have an idea for a trivial change to generate Unicode property 
tables translated into EBCDIC, and that might make the rest of the code 
cleaner in a number of places.)

But without a test bed, we would never be sure that anything we do 
actually works.

It's likely that many CPAN modules are written without consideration of 
EBCDIC.  Some of these are easy to fix.  For example, hard-coded hex 
character constants can be made to work simply by writing, e.g. \N{U+DF} 
instead of \x{DF}.  The distinction between the UTF forms is harder to 
deal with.  As are assumptions like the ordinal of I is 1 less than the 
ordinal of J.  I have no idea how common those things are in modules, 
but I do know that most of those are ok in the Perl core.

I wasn't around at the time, but I have gotten the sense that there is 
bad blood between IBM and the Perl developer community.  IBM appears to 
be unwilling to do anything until and if there is sufficient demand from 
its current or potential customers.  If none of those customers can 
offer us computer time for testing, that tells me there is insufficient 
demand for up-to-date Perls.

> -----Original Message-----
> From: Dean, Sandy
> Sent: Wednesday, September 28, 2011 6:41 AM
> To: Nicholas Clark; Terwedow, Egon (E.)
> Cc: Craig A. Berry; Jesse Vincent; Perl5 Porters;
> Subject: RE: Speak up now about your use of EBCDIC or WE WILL REMOVE IT in a future release of Perl
> I will ask IBM.
> Sandy Dean
> -----Original Message-----
> From: Nicholas Clark [] On Behalf Of Nicholas Clark
> Sent: Monday, September 26, 2011 2:47 PM
> To: Terwedow, Egon (E.)
> Cc: Craig A. Berry; Jesse Vincent; Perl5 Porters;
> Subject: Re: Speak up now about your use of EBCDIC or WE WILL REMOVE IT in a future release of Perl
> On Mon, Sep 26, 2011 at 06:41:03AM +0000, Terwedow, Egon (E.) wrote:
>> Hello,
>> We still customize Perl in our USS environment and we use it in a few of our web interfaces. I would appreciate if the open source community will continue to support the product.
> We simply aren't in a position to support the product, unaided.
> None of the current core perl developers have access to any EBCDIC platform
> since they became core developers. Those core developers that did have
> access did so nearly 10 years ago, and have either moved to other projects
> or died. IBM does not offer any sort access to EBCDIC based systems for us
> to test things.
>> This is not highest priority and we do not need latest releases in line with the rest of the Perl community but it would be important to continue the IBM open source commitment to have Perl on the list of supported products.
>> Please let me know if you decide to stop the support for Perl so that I can inform the user community in my company that this is no longer a viable solution.
> De facto there is already no support from the community for Perl on EBCDIC
> platforms, because the community has *no* access to them, or proxy access
> via the "remote hands" of volunteers.
> Note also that removing the EBCDIC-related code from the current version in
> no way actually changes your current situation. Nor does leaving it in.
> Removing it won't overnight stop the code you have from working.
> Leaving it in won't make the current version work on EBCDIC.
> Either way, your code is just as supported tomorrow as it was yesterday.
> ie it's not. (Unless you have a support contract from IBM that I'm not
> aware of.)
> We've already dropped support for 5.8.x and 5.10.x, across the board.
> (I'm guessing that EBCDIC users are on 5.8.x or earlier)
> Really we need help (money alone won't cut it, unless it's enough to *buy*,
> host and maintain an EBCDIC system) from either EBCDIC users who value Perl,
> or IBM, as the vendor whose commercial platform benefits from having Perl
> working on it.
> It would be helpful to us, if EBCDIC users, as IBM customers, were to ask
> IBM how IBM plan to help support Perl on EBCDIC.
> Nicholas Clark

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