On Tue, 22 Jan 2019 17:42:23 -0600, Kirk Wolf wrote:
>I've noticed that one *some* z/OS systems that the first call to the
>resolver by a Unix process takes an extra 1/2 second or more.
>Does anyone have any clues as to why this would be?
It couldn't possibly be a migrated data set or something,
.223 secs is a little less than half of what I get on one system, but on
another I see less than .002 secs
On Wed, Jan 23, 2019 at 11:54 AM Gord Tomlin <
gt.ibm.li...@actionsoftware.com> wrote:
> On 2019-01-23 11:39, Kirk Wolf wrote:
> > RESOLVER_TRACE=STDOUT host 127.0.0.1 >restest1.txt
> When
For the volumes outside the storage group, it did. IBM is looking to see if
it took DAYS(0) as a default.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Hervey Martinez
Sent: Wednesday, January 23, 2019 1:35 PM
To:
Hi Chuck,
So, what you're saying is that the command ignored management class attributes
for each of these files?
Hervey
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Chuck Kreiter
Sent: Wednesday, January 23, 2019 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject:
My firm was recently hit with a bug in the MIGRATE STORAGEGROUP command.
When issued, HSM began migrating the storage group requested but then moved
on to other volumes in different storage groups. We discovered this after
several CICS datasets were migrated while the region was down and the
for mounts or remounts - same here, I just run a BPXBATCH to run the automount
Carmen Vitullo
- Original Message -
From: "Philip S. Watkins"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, January 23, 2019 11:27:31 AM
Subject: Re: NFS Mount Failure
My unmount and mounts are
On 2019-01-23 11:39, Kirk Wolf wrote:
RESOLVER_TRACE=STDOUT host 127.0.0.1 >restest1.txt
When I use the above test command, I am consistently seeing about a
0.22-0.23 second delay between "Resolver Trace Initialization Complete"
and "res_init Started", for example (lines without time stamps
My unmount and mounts are issued via batch from the mainframe. What about yours?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Wednesday, January 23, 2019 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Mount Failure
CAUTION: This email
that's the process we follow also unfortunately
Carmen Vitullo
- Original Message -
From: "Philip S. Watkins"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, January 23, 2019 10:54:29 AM
Subject: Re: NFS Mount Failure
I set up a process to unmount the file server and mount it
In particular, you don't get any of the financial crypto verbs without a Crypto
Express. The standards do not allow banks to perform functions like those
unless they are executed in a physically and logically secure crypto device.
I set up a process to unmount the file server and mount it again before the
transfer job runs and it still requires at times to browse the USS file to
recover.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Wednesday, January 23, 2019 11:42
I'm not an NFS expert but we do have NFS to Windows and HP/UX, for us once the
server is backup and a connection is requested on the 'Z' side the mount is re
established, or we run the automount for nfs, but that's really not necessary
for one server connection.
Carmen Vitullo
-
Thanks Gord, but:
I don't think that a slow DNS lookup is the problem.
- The call that I'm making doesn't even do a lookup AFAIK.
- The lost time, according to the resolver trace, is before my
getaddrinfo() api call even starts. It appears to be something that
happens during initialization of
We have an NFS mount from the z/OS 1.13 mainframe to a windows 2012 server.
Whenever the server is rebooted communication is lost between the two. I can
run an unmount and mount from the mainframe but it does not cause files on the
directory to be accessible. The mainframe shows the NFS mount
On 2019-01-23 08:27, Kirk Wolf wrote:
I had the same thought Gord.
I already tried changing the default "LOOKUP DNS LOCAL" to "LOOKUP DNS"
and that didn't change anything.
Did you try the reverse, i.e., "LOOKUP LOCAL DNS"?
TRACE RESOLVER might also provide some additional insight. One of
Thanks Todd,
Please confirm: A0 was the first release where a card was not required for
/dev/random (but ICSF was required to be started). If so, how was it done
in ICSF? Your note only mentions how it was done if you had a card.
On Wed, Jan 23, 2019 at 8:06 AM Todd Arnold wrote:
> There
W dniu 2019-01-22 o 23:39, Greg Boyd pisze:
Lots of good stuff on IBM-MAIN this week! :-)
Take a look at http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5120
The title is 'dhppkeys exec to Display PassPhrase Generated Master Key Values'.
And I have to ask ... why are you still
There have been several changes over the years to improve performance of random
number generation, but the important thing is that the random numbers were
always generated using secure methods. As Greg mentioned, ICSF started using
the CEX long ago to get random numbers, which were generated
Gary: Thanks for the pointer to OA55437, I was not aware of that APAR. It
specifically says that /dev/random uses the TRNG (True Random Number Generator)
which is implemented on the CPACF.
Kirk: RNGCACHE was introduced with HCR77B0 (the first time I see it is in the
ICSF SPG is
Gary,
That is correct, but I was asking about (before OA55437) whether when using
ICSF for /dev/random whether a card was used and if so whether it makes any
difference.
On Tue, Jan 22, 2019 at 6:09 PM Gary Freestone wrote:
> This was announced by IBM last August.
>
> “With the PTFs for APAR
I had the same thought Gord.
I already tried changing the default "LOOKUP DNS LOCAL" to "LOOKUP DNS"
and that didn't change anything.
On Tue, Jan 22, 2019 at 10:44 PM Gord Tomlin <
gt.ibm.li...@actionsoftware.com> wrote:
> On 2019-01-22 18:42, Kirk Wolf wrote:
> > I've noticed that one *some*
21 matches
Mail list logo
