В Ср., 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.
>
>
> Sandra
>
>
> -----Original Message-----
> From: Yaroslav Kuzmin [mailto:ykuz...@rocketsoftware.com]
> Sent: Wednesday, July 27, 2016 8:51 AM
> To: Carroll, Sandra E (Sandra) <carr...@nationwide.com>; perl-mvs@perl.org
> Cc: perl5-port...@perl.org
> 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.
================================
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