RE: Re: Smoke [blead] v5.25.7-50-g4f738c7 FAIL(X) os/390 25.00 (2964/)
Karl,
I took a look at Net::Ping
Pingecho is a wrapper for ping from what I see.
sub pingecho
{
my ($host, # Name or IP number of host to ping
$timeout# Optional timeout in seconds
) = @_;
my ($p);# A ping object
$p = Net::Ping->new("tcp", $timeout);
$p->ping($host);# Going out of scope closes the connection
}
Which in turn calls ping
# Description: Ping a host name or IP number with an optional timeout.
# First lookup the host, and return undef if it is not found. Otherwise
# perform the specific ping method based on the protocol. Return the
# result of the ping.
sub ping
{
my ($self,
$host, # Name or IP number of host to ping
$timeout, # Seconds after which ping times out
$family,# Address family
) = @_;
my ($ip,# Hash of addr (string), addr_in (packed), family
$ret, # The return value
$ping_time, # When ping began
);
$host = $self->{host} if !defined $host and $self->{host};
croak("Usage: \$p->ping([ \$host [, \$timeout [, \$family]]])") if @_ > 4 or
!$host;
$timeout = $self->{timeout} unless $timeout;
croak("Timeout must be greater than 0 seconds") if $timeout <= 0;
if ($family) {
if ($family =~ $qr_family) {
if ($family =~ $qr_family4) {
$self->{family_local} = AF_INET;
} else {
$self->{family_local} = $AF_INET6;
}
} else {
croak('Family must be "ipv4" or "ipv6"')
}
} else {
$self->{family_local} = $self->{family};
}
$ip = $self->_resolv($host);
return () unless defined($ip); # Does host exist?
# Dispatch to the appropriate routine.
$ping_time = ();
if ($self->{proto} eq "external") {
$ret = $self->ping_external($ip, $timeout);
}
elsif ($self->{proto} eq "udp") {
$ret = $self->ping_udp($ip, $timeout);
}
elsif ($self->{proto} eq "icmp") {
$ret = $self->ping_icmp($ip, $timeout);
}
elsif ($self->{proto} eq "icmpv6") {
$ret = $self->ping_icmpv6($ip, $timeout);
}
elsif ($self->{proto} eq "tcp") {
$ret = $self->ping_tcp($ip, $timeout);
}
elsif ($self->{proto} eq "stream") {
$ret = $self->ping_stream($ip, $timeout);
}
elsif ($self->{proto} eq "syn") {
$ret = $self->ping_syn($host, $ip, $ping_time, $ping_time+$timeout);
} else {
croak("Unknown protocol \"$self->{proto}\" in ping()");
}
return wantarray ? ($ret, () - $ping_time, $self->ntop($ip)) : $ret;
}
It has many return values so what would be helpful is knowing what Yaroslav's
system is returning so see where it is dying.
I'm happy to help figure it out if you need the help.
I have a few thoughts that could be system dependent but knowing the exact
return code would help allot.
Sandra
P.S. sorry for the code paste in the thread
-Original Message-
From: Karl Williamson [mailto:pub...@khwilliamson.com]
Sent: Wednesday, December 07, 2016 1:09 AM
To: Yaroslav Kuzmin ; perl-mvs@perl.org;
perl5-port...@perl.org
Cc: daily-build-repo...@perl.org
Subject: [EXTERNAL] Re: Smoke [blead] v5.25.7-50-g4f738c7 FAIL(X) os/390 25.00
(2964/)
Nationwide Information Security Warning: This is an external email. Do not
click on links or open attachments unless you trust the sender.
--
On 12/06/2016 04:26 AM, Yaroslav Kuzmin wrote:
>
> Smoke log at available
> https://drive.google.com/file/d/0B5PTttxwo7qAdG1UbDdncHNOdG8
>
> Automated smoke report for branch blead 5.25.8 patch
> 4f738c750ddb40ef82b46158f89572739a8b186a v5.25.7-50-g4f738c7
> RS12: 2964 (2964/)
> onos/390 - 25.00
> using c99 version
> smoketime 5 hours 17 minutes (average 2 hours 38 minutes)
>
> Summary: FAIL(X)
>
> O = OK F = Failure(s), extended report at the bottom X = Failure(s)
> under TEST but not under harness ? = still running or test results
> not (yet) available
> Build failures during: - = unknown or N/A
> c = Configure, m = make, M = make (after miniperl), t = make
> test-prep
>
> v5.25.7-50-g4f738c7 Configuration (common) none
> --- -
> X X X X -Dusedl
> | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio
> -DDEBUGGING | +- PERLIO = perlio
> +--- PERLIO = stdio
>
>
> Locally applied patches:
> SMOKE4f738c750ddb40ef82b46158f89572739a8b186a
>
> Tests skipped on user request:
> # One test name on a line
> Failures: (common-args) none
> [stdio] -Dusedl
> Inconsistent test results (between TEST and harness):
> ../ext/XS-APItest/t/utf8.t..
> . FAILED at test 157018
> ../t/dist/Net-Ping/t/010_pingecho.t.
> .. FAILED at test 2
>
RE: ASCII support in z/OS
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 +, 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
RE: ASCII support in z/OS
Just want to Thank Yaroslav Kuzmin and Karl Williamson for you work on perl for z/OS. It is very much appreciated Sandra -Original Message- From: Karl Williamson [mailto:pub...@khwilliamson.com] Sent: Tuesday, August 02, 2016 11:54 PM To: John Goodyear <johng...@us.ibm.com>; Yaroslav Kuzmin <ykuz...@rocketsoftware.com> Cc: Carroll, Sandra E (Sandra) <carr...@nationwide.com>; perl-mvs@perl.org; perl5-port...@perl.org Subject: Re: ASCII support in z/OS 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 +, 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 S
RE: ASCII support in z/OS
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 -Original Message- From: Yaroslav Kuzmin [mailto:ykuz...@rocketsoftware.com] Sent: Wednesday, July 27, 2016 7:57 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 Hi Carroll If you use scripts in encoding IBM-1047 on USS z/OS it is not a problem. You can set filetag encoding using tool (chtag -t -c IBM-1047 ) -- 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 В Вт., 26/07/2016 в 11:51 +, Carroll, Sandra E (Sandra) пишет: > It depends, > I know I use no ASCII in any scripts (no need for it) I'm using perl for > system usage. I'm > working with z/OS EBCDIC Datasets, RACF and other files that are native > EBCDIC. I need my files > stored and maintained as EBCDIC. If it doesn't break that, I have no > opinion. If it breaks that > and starts creating files in in ASCII on z/OS then I have a problem. > > Websphere is a royal PITA due to its asci support. > > Sandra > > > > -Original Message- > From: Yaroslav Kuzmin [mailto:ykuz...@rocketsoftware.com] > Sent: Tuesday, July 26, 2016 7:44 AM > To: perl-mvs@perl.org > Cc: perl5-port...@perl.org > Subject: ASCII support in z/OS > > Hi All, > > IBM offers all tools build with 'ASCII support' for USS z/OS. > > Overview: > Enhanced ASCII support is a collection of services and options for > dealing with the EBCDIC/ASCII problem. : > > Files can be "tagged" (using chtag ) to indicate whether or not > they are pure text files, and if they are, the character set (CCSID) > used to encode them. The typical values will be "1047" (for > ibm- > 1047) or "819" (for iso8859-1). > C/C++ programs can be compiled such that all the character and > string constants in the program are compiled into ASCII (or other code page, > for that matter), rather than EBCDIC. > C/C++ programs are marked with a "program CCSID" that indicates > the character set the program uses internally. Note that all programs have a > program CCSID, > Given a tagged file, data can automatically be converted from one > code page to another when the file is read or written. > > > Documentation: > Unix System Services Planning > Chapter 11 (Converting files between code pages), section > "Using Enhanced ASCII" (http://w ww > .ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/uenha.htm), > provides an overview of how to setup and use Enhanced ASCII support. > Unix System Services (USS z/OS) Command Reference contains details on > these commands: > chtag - query/change the file type (binary/text) and codeset > information for a file. > ls - the -T flag can be used to display file tag information. > pax - interchange portable archives. pax can record (on > archive) and honor (on restore) file tag information. > tar - similar to pax. z/OS tar supports processing of file tags. > XL C/C++ Programming Guide > Chapter 11 (Performing z/OS UNIX file system I/O operations), > section "File tagging and conversion" > (http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zo > s.v2r2.cbcpx01/c > bc > 1p273.htm), discusses file tagging, the notion of a program's CCSID, > and various facilities related to enhanced ASCII support > Chapter 32 "Using environment variables" > (http://www.ibm.com/support/knowledgecenter/en/SS > LT > BW_2.2.0/com.ibm.zos.v2r2.cbcpx01/setenv.htm) has very good > information and descriptions of specific environment variables (see below). > > XL C/C++ Runtime Library Reference > Appendix B (Function support table), section "Enhanced ASCII > support" (http://www.ibm.com/ su > pport/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxbd00/enhasci > i.htm) has a good discussion of the feature test macros defined for > various levels of e
