Re: [a-z] class in EBCDIC and Perl-MVS status question

On 06/18/2015 09:01 AM, Atlas, Ze'Ev wrote:
> Hi all
>
> 1.  In the last few months, I see periodically, some email speaking
> about 'smoke' tests.  Some pass and some fail.  It is not clear whether
> Perl for z/OS is ready or not.  Could somebody please shed some lite on
> the situation.  And if it is stable, where could I download it from
> (including installation instructions.)

Perl 5.22 is a stable version which passes the smoke tests on z/OS, 
which is the system I presume you are operating on.  We are working on 
making the EBCDIC easily accessible, besides what Rocket is doing.  If 
you want to get started now, you can download the source at
http://www.cpan.org/src/README.html

Before proceeding with the installation, you need to unpack the source 
and convert it from UTF-8 to UTF-EBCDIC.  You can run the program that 
Yaroslav has published to do the conversion, found by searching the 
internet for
<[email protected]>
(This is a binary; source was published instead in
<[email protected]>

After doing this you can compile and test as described in
http://www.cpan.org/src/README.html

>
> 2. The Perlre in perldocs (5.20), document states:
>
>   (The following all specify the same class of three characters: [-az] ,
> [az-] , and [a\-z] . All are different from [a-z] , which specifies a
> class containing twenty-six characters, even on EBCDIC-based character
> sets.)
>
> The implication is that Perl somehow recognizes [a-z] and treats it as a
> special case in EBCDIC and ignore the non-letters gaps.  Do I understand
> it correctly and is it implemented as advertised?
>
> Ze'ev Atlas

Yes it is implemented as advertised.  If you do want to include the gap 
characters, you can instead write [\x81-\xA9].  But when both ends of 
the range are literals, like "A", and the range is any subset of [A-Z] 
or [a-z], special handling is invoked internally to exclude the gap 
characters.

The 5.22 EBCDIC documentation has been extensively revised by me to 
accurately reflect the actual implementation.  Please file a bug report 
on any discrepancies.  There are some known bugs in the EBCDIC version 
not present when run on ASCII platforms.  Unfortunately, the 
documentation on the web hasn't been properly updated yet to reflect 
5.22.  Here's what the new perlebcdic says about known EBCDIC problems:

      *   The "cmp" (and hence "sort") operators do not necessarily give the
          correct results when both operands are UTF-EBCDIC encoded 
strings and
          there is a mixture of ASCII and/or control characters, along with
          other characters.

      *   Ranges containing "\N{...}" in the "tr///" (and "y///")
          transliteration operators are treated differently than the 
equivalent
          ranges in regular expression patterns. They should, but don't, 
cause
          the values in the ranges to all be treated as Unicode code 
points, and
          not native ones. ("Version 8 Regular Expressions" in perlre gives
          details as to how it should work.)

      *   There are some bugs in the "pack"/"unpack" "U0" template

      *   There are a significant number of test failures in the CPAN 
modules
          shipped with Perl v5.22. These are only in modules not primarily
          maintained by Perl 5 porters. Some of these are failures in 
the tests
          only: they don't realize that it is proper to get different 
results on
          EBCDIC platforms. And some of the failures are real bugs. If you
          compile and do a "make test" on Perl, all tests on the "/cpan"
          directory are skipped.

          In particular, the extensions Unicode::Collate and 
Unicode::Normalize
          are not supported under EBCDIC; likewise for the (now deprecated)
          encoding pragma.

          Encode partially works.

>