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.


Regards,

John Goodyear
z Systems Analytics zChampion
WSC z Systems Applied Technologies
Herndon, VA
johng...@us.ibm.com

I agree with John about the need to continue to support the 1047-based perl.

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 <ykuz...@rocketsoftware.com>
To: "carr...@nationwide.com" <carr...@nationwide.com>,
"perl-mvs@perl.org" <perl-mvs@perl.org>
Cc: "perl5-port...@perl.org" <perl5-port...@perl.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
USS.
and is able to build newer versions of the tools with minimum work on
porting.


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 .

--

Regards,

Yaroslav Kuzmin
Developer C/C++ ,z/OS , Linux
3 Zhukovskiy Street · Miass, Chelyabinsk region 456318 · Russia
Tel:  +7.922.2.38.33.38
Email: ykuz...@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?

Sandra



================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
02451 ■ +1 877.328.2932 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences -
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

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.




Reply via email to