Re: [perl #131057] Perl on EBCDIC platform

On 03/29/2017 03:29 PM, Dick Franks wrote:
>
> On 29 March 2017 at 21:18, karl williamson via RT
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>     I'm willing to look at your code for obvious EBCDIC issues if you want
>     to post it or email it to me.
>
>
> Thanks for showing an interest.
>
> However, there is no substitute for running tests in a real EBCDIC
> environment.
>
> Proof of the pudding is in the eating, not reading the recipe.
>
> If you know anyone with some real kit, please encourage them to get in
> touch.
>
>
> Regards
>
> --Dick
>

If anyone with real hardware is willing to help you, they will be on the 
mvs list, and can respond.  Such hardware is hard to come by, and tends 
to not be directly connected to the internet, so testing DNS things 
might not be feasible.

The ticket was closed because this is not a perl bug, but a request for 
assistance, which has been redirected to the appropriate channel.

I could have likely quickly told you if the code was on the right track 
to be EBCDIC compatible.  Properly written Perl and XS code should 
rarely need to have separate paths for the two character sets.  (There 
are only a few in all of the Perl core.)  If your code had such paths, 
that part is probably wrong, and should be thrown away.  Documentation 
is in perlebcdic and perlhacktips (the latter for XS code and .t tests). 
  See also the documentation for the utf8 module which gives functions 
that can be used to portably specify any character.  (These functions 
aren't related to utf8, and were placed in this module for convenience, 
where they remain).

The most typical failures are in .t files.  A lot of tests tend to be 
written expecting a particular bit pattern result related to character 
sets, and these will show as failures, even if the module actually 
works.  perlhacktips gives suggestions for writing portable tests.