Front page | perl.perl5.porters |
Postings from August 2016
Re: ASCII support in z/OS
From: Yaroslav Kuzmin
August 5, 2016 09:56
Re: ASCII support in z/OS
Message ID: firstname.lastname@example.org
В Ср., 27/07/2016 в 13:06 +0000, Carroll, Sandra E (Sandra) пишет:
> I hope I'm understanding you on this.
> Users of perl on z/OS, work almost exclusively in EBCDIC.
> I understand from a porting Point of view. However if fixing a porting issue introduces to USS
> (OMVS) that our files are ASCII encoded.
> I do not believe you'll find many users who will find that acceptable. I do not find it
> acceptable myself.
> I am talking purely from the end user POV, ascii encoding is useless to many if not all of
> us. If it introduces the need for us to chtag files so we can encode them basic to EBCDIC the way
> they should have been encoded by default. The overhead of doing work on zOS jumps and the value of
> perl goes down.
Of course users in the z/OS are working exclusively whit encoded EBCDIC. But the new program does
not support the encoding EBCDIC. But in new programs need is there on z/OS. Therefore, the use of
ASCII support on z/OS makes it easy to running new programs with minimal modifications, you need
only include the ASCII support system in the program.
Of course users on z/OS you want to control and set the tag for all files using chtag. But the more
programs will use the ASCII support the less you need to install the tag in the manual mode using
chtag. When using programs with ASCII support so it tag will be set automatically . Users need
only turn on ASCII support system by setting environment variable (_BPXK_AUTOCVT=ON) in USS z/OS.
> Remember, we don't exclusively work in OMVS. Most of what we'll do is z/OS datasets those
> have no CHTAG option.
> Coping to USS is often not an option either due to size or confidentiality/integrity of data
> especially in the financial industry.
> That said, what perl does internally, I don’t' care, what perl does to files and datasets I do
> care very much.
> A file with no chtag should be read as EBCDIC
> A file with a chtag of ISO-885901 should be read as ASCII.
> -----Original Message-----
> From: Yaroslav Kuzmin [mailto:email@example.com]
> Sent: Wednesday, July 27, 2016 8:51 AM
> To: Carroll, Sandra E (Sandra) <CARROS1@nationwide.com>; firstname.lastname@example.org
> Cc: email@example.com
> 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 .
> 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?
> > Sandra
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 877.328.2932 ■ +1
> 781.577.4321 Unsubscribe From Commercial Email – firstname.lastname@example.org Manage Your
> Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_
> 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.
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 - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
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.