Front page | perl.perl5.porters |
Postings from August 2016
Re: ASCII support in z/OS
From: Karl Williamson
August 3, 2016 03:53
Re: ASCII support in z/OS
Message ID: email@example.com
On 07/27/2016 09:18 AM, John Goodyear wrote:
> While it is valuable to get ASCII support for PERL on z/OS for reasons
> such as git, I think other z/OS PERL users will have similar issues that
> Sandra has voiced. Not everyone is reading/writing to Unix files on
> z/OS, so chtag wouldn't help. Even if chtag is beneficial, it means
> changing scripts/procedures to accommodate the new behavior. Also, if
> the new PERL would wants to generate ASCII output by default, there is
> further modification to scripts ect... to tell it to generate EBCDIC
> It seems the best solution from a usability standpoint is to be able to
> build PERL so that it works on z/OS as before, or build it so that it
> assumes the new behavior you are targeting to support git and other
> software with PERL dependencies.
> John Goodyear
> z Systems Analytics zChampion
> WSC z Systems Applied Technologies
> Herndon, VA
I agree with John about the need to continue to support the 1047-based
I suspect that it won't be too hard to get a Perl working in ASCII mode.
If you can figure out a way to get the hints file to work on both
styles, that would be preferable, as a bunch of system information in it
is applicable to the underlying operating system, and having two files
would invite one getting updated and forgetting the other.
Note that the perl Encode module can be used to translate to/from a data
file in many many character sets/code pages to what perl is expecting.
There are bugs with it on z/OS that I have not yet addressed, however.
If I recall correctly, though, the ASCII/EBCDIC switch is not easily
changeable per process or even per user. I thought it was an everything
on the machine or nothing type of deal, which, if so, is problematic.
Hopefully, I'm wrong.
> Inactive hide details for Yaroslav Kuzmin ---07/27/2016 08:51:20
> AM---The main problem, obtain new tools to z/OS. tools is verYaroslav
> Kuzmin ---07/27/2016 08:51:20 AM---The main problem, obtain new tools to
> z/OS. tools is very outdated on USS z/OS. This will leave the
> From: Yaroslav Kuzmin <firstname.lastname@example.org>
> To: "CARROS1@nationwide.com" <CARROS1@nationwide.com>,
> "email@example.com" <firstname.lastname@example.org>
> Cc: "email@example.com" <firstname.lastname@example.org>
> Date: 07/27/2016 08:51 AM
> Subject: Re: ASCII support in z/OS
> The main problem, obtain new tools to z/OS. tools is very outdated on
> USS z/OS.
> This will leave the encoding EBCDIC and go to the encoding ISO-8859-1 on
> and is able to build newer versions of the tools with minimum work on
> If the community perl knows about encoding EBCDIC , the community git
> does not know about it.
> turn on the system ASCII support is much easier than working with the
> encoding EBCDIC .
> Yaroslav Kuzmin
> Developer C/C++ ,z/OS , Linux
> 3 Zhukovskiy Street · Miass, Chelyabinsk region 456318 · Russia
> Tel: +7.918.104.22.168.38
> Email: YKuzmin@rocketsoftware.com
> Web: www.rocketsoftware.com
> В Ср., 27/07/2016 в 12:30 +0000, Carroll, Sandra E (Sandra) пишет:
>> 100% of what I do, and many (if not most all) on z/OS is EBCDIC based
> not ASCII based.
>> We do not want or need our files ascii encoded by default if that's
> what you're suggesting.
>> Being able to natively read a ascii file is a plus but native encoding
> needs to remain EBCDIC.
>> That would be like making EBCDIC the default encoding on Linux.
>> what we do is parsing 5-10 million line per day per system log files
> (so over 100 million lines)
>> that are MVS (not USS) datasets.
>> My question is what perceived problem are you trying to fix?
>> Is this to make porting easier or is it to fix a problem accessing
> files on zOS?
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ +1 877.328.2932 ■ +1 781.577.4321
> Unsubscribe From Commercial Email – email@example.com
> Manage Your Subscription Preferences -
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.