Problem statement and some background: The Perl 5 porters want to
remove and/or disable the EBCDIC support from the current Perl 5
source code base because they have no way of knowing whether it still
works. (Background: Perl 5 has within last few years moved to a much
more frequent release schedule.)
Perl 5 gained EBCDIC support in the early 5.8.x timeframe, in
conjunction with the push for better Unicode/UTF-8 support. The
problem there is that 5.8.0 was released in July 2002, more than 9
years ago. Perl 5 is currently at 5.14, in May 2011. All Perl 5.8
releases were end-of-lifed in 2008.
IBM is maintaining their own fork of Perl 5.8 on z/so, apparently
5.8.7, as part of open source tools for z/os. While there has been in
the past some communication with IBM and the perl5-porters, it has not
been very regular, and the IBM people seem to be operating under some
internal restrictions (like not communicating about the content of
their suggested changes).
The EBCDIC systems (IBM mainframes running z/os or their close
variants in other similar mainframes, BUT NOT the Linux-on-z/os which
uses ASCII) are rare, and because of their multi-million dollar price
tags, and often financially related applications, they are closely
guarded by their users. Therefore getting random open source
developers any access to the systems is really hard. (Perl 5 porters
lucked out in early 5.8 in that they had access to not just one but
two z/os systems, one within Texas Instruments, and one in an IBM
development center. Unfortunately these accesses no more exist, and
it has been proven extraordinarily hard to find any people within IBM
that would make them arrange software development access to anyone
external.)
Therefore I think the only way forward is that the users of
Perl-on-EBCDIC convince IBM z/os division of the importance of having
a modern maintained Perl on their systems. Of course the case may be
that there is not high enough importance. NOTE: the answer of 'IBM is
maintaining their own fork' is useless *unless* IBM really keeps the
fork up-to-date. A deprecated version is not good enough, and will
eventually become too burdensome for IBM to maintain. The
UTF-8/UTF-EBCDIC part of the port is especially thorny: one needs to
have a good understanding of how Perl 5 implements Unicode.
Suggested ways forward (these are not mutually exclusive, any single
one of them would break the impasse we have now):
(1) one or more perl-on-EBCDIC users (their internal tools support
people, for example) help the perl5-porters with one or more of the
following (a continuum of possibilities):
(a) set up a regular "smoke build" where the perl 5 source is
fetched, built, and tested, and the results sent out to the
perl5-porteres, who can then assist in resolving any issues found
(b) the internal tools support tries to build and test perl 5, and
consult the perl5-porters with any issues found
(c) the company (or whatever) trusts a perl5-porter enough to
arrange for an actual login to z/os system, so that the porter can do
the build and resolve the issues (I for example managed to get access
to an IBM system by physically showing up in an IBM lab, and signing
the paperwork of promising not to do bad things)
(2) one or more perl-on-EBCDIC users firmly ask IBM to give up on
their current "fork" and instead work more closely with the Perl 5
open source project (aka perl5-porters)
The spectrum here is similar to option (1): depending on how much
IBM wants to do themselves, and how much they want to interact with
the perl5-porters.
--
There is this special biologist word we use for 'stable'. It is
'dead'. -- Jack Cohen
