Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
a concrete proposal for the continued support of EBCDIC in Perl
4 views
Skip to first unread message
Jarkko Hietaniemi
Oct 3, 2011, 6:18:55 AM10/3/11
to Perl5 Porters, perl...@perl.org
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
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
Jarkko Hietaniemi
Oct 3, 2011, 6:58:16 AM10/3/11
to Henry Yen, Perl5 Porters, perl...@perl.org
If you have a genuine EBCDIC environment, yes, that would help
immensely. The old OS might require some tweaking of the build
process, e.g. the hints/*.sh, but the EBCDICness would be very useful.
(Of course, if you have never built Perl 5 on this system, you might
have quite a few initial hurdles before getting to 'make test'
stage...)
If you have the time time, yes, please do try building Perl 5.14 on
this system, or probably preferably even the 5.15 development branch.
I'm certain perl5-porters will be more than happy to help you.
On Mon, Oct 3, 2011 at 12:32 PM, Henry Yen <he...@aegisinfosys.com> wrote:
> emulator. Although access to a modern z/OS software system still
> requires effort and/or money, access to genuine hardware isn't
> necessarily an impediment?
>
> --
> Henry Yen <Henr...@Aegis00.com> Aegis Information Systems, Inc.
> Senior Systems Programmer Hicksville, New York
> (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700)
immensely. The old OS might require some tweaking of the build
process, e.g. the hints/*.sh, but the EBCDICness would be very useful.
(Of course, if you have never built Perl 5 on this system, you might
have quite a few initial hurdles before getting to 'make test'
stage...)
If you have the time time, yes, please do try building Perl 5.14 on
this system, or probably preferably even the 5.15 development branch.
I'm certain perl5-porters will be more than happy to help you.
On Mon, Oct 3, 2011 at 12:32 PM, Henry Yen <he...@aegisinfosys.com> wrote:
> On Mon, Oct 03, 2011 at 12:18:55PM +0200, Jarkko Hietaniemi wrote:
>> 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.)
>
> I still run the old "public-domain"-ish MVS 3.8 and VMr6 on a Hercules
>> 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.)
>
> emulator. Although access to a modern z/OS software system still
> requires effort and/or money, access to genuine hardware isn't
> necessarily an impediment?
>
> --
> Henry Yen <Henr...@Aegis00.com> Aegis Information Systems, Inc.
> Senior Systems Programmer Hicksville, New York
> (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700)
Peter Prymmer
Oct 3, 2011, 1:22:04 PM10/3/11
to Joe McMahon, j...@iki.fi, Henry Yen, Perl5 Porters, perl...@perl.org
For OS/390 and z/OS the perl build was only supported under the Unix System Services subsystem. I do not think that is supported
under older versions of MVS, but I am not sure how far back in MVS versions it could be run.
under older versions of MVS, but I am not sure how far back in MVS versions it could be run.
Peter Prymmer
Joe McMahon
Oct 3, 2011, 11:23:16 AM10/3/11
to j...@iki.fi, Henry Yen, Perl5 Porters, perl...@perl.org
Please keep us informed on this - I remember enough of my MVS systems programming skills to run a Hercules emulator MVS here as well if it will work for a smoke platform. Insufficient round tuits at the moment to start working out the build environment from scratch, though.
MVS is a real EBCDIC system, though an older one (IBM's gone through 3 OS architecture transitions at this point, starting at MVS). It should be "good enough" to test the EBCDIC code on.
Jarkko Hietaniemi
Oct 4, 2011, 5:04:28 AM10/4/11
to Perl5 Porters, perl...@perl.org
FWIW, I'm trying to use my old contacts within IBM to find the people
dealing with z/os open source tools, or whatever it is they call Perl
5.
dealing with z/os open source tools, or whatever it is they call Perl
5.
0 new messages