Sorry, you're missing the key point. We're not all working in USS. We cannot chtag a dataset on zOS. That can only be done to files in USS. This is asking z/OS users to possibly completely recode jobs (JCL) that run. Possibly rewrite existing perl scripts as well. I sometimes have mixed EBCDIC/BINARY datasets, how do I deal with those?
For example we open to a read a dataset PSYS.CICS.LOG.A20160404 in perl, that is not a file in USS . That dataset will be in EBCDIC. Not ASCII. _BPXK_AUTOCVT=ON only applies to USS Files, not Datasets. To be frank, if I have to start coping and converting datasets to USS files in ASCII. I will not use perl. I will rewrite in rexx and pull down the regex support package out there. I'm sorry to be blunt, but a perl on z/OS that cannot process native z/OS datasets is useless to me. Again, it's like asking everyone in the ASCII community to give up ASCII and live in a EBCDIC world. That's not going to happen. Others may feel different and have different opinions. It's hard enough to get z/OS people to use perl over rexx as is. Tell them they'll have to copy files to USS and make sure to convert to ascii will put up a red flag to any z/OS person IMHO. I highly suggest you reconsider doing this. I've not read yet what compelling reason there is that is forcing this. I read a choice being made. I've not read the perl community is forcing EBCDIC to go away and be all ASCII. So why must we do this? Why would you force end users to change to make coding easier especially for a fundamental issue like this. Sorry for the long email and jumping around a bit. Sandra -----Original Message----- From: Yaroslav Kuzmin [mailto:ykuz...@rocketsoftware.com] Sent: Friday, August 05, 2016 5:56 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 В Ср., 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.
