NTAC:3NS-20
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
NTAC:3NS-20
We are currently running MQ V7.1 (z/OS 2.2) and plan to migrate to V9 early
next year.
A couple of weeks ago we had an issue where a application 'audit queue'
residing in pageset 01, along with the dynamic command queues, filled up the
pageset due to an application error. This
Marchant
Sent: Thursday, December 29, 2016 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recommendations for RECOVERY options
On Thu, 29 Dec 2016 13:45:53 +, James Peddycord wrote:
>In this forum with so many people who have so many opinions, I can't
>believe that nobody is of
Subject: Re: Recommendations for RECOVERY options
James Peddycord wrote:
>In this forum with so many people who have so many opinions, I can't
believe that nobody is offering suggestions for the RECOVERY parameter
when asked.
Perhaps these persons with that specific hardware combination are st
-
From: James Peddycord [mailto:j...@ntrs.com]
Sent: 28 December 2016 4:56 pm
Subject: Recommendations for RECOVERY options
NTAC:3NS-20
We had a situation with a bad cable that resulted in a huge performance
impact due to the default way that z/OS (we are at 1.13) handles error
recovery on Ficon
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of James Peddycord
Sent: Wednesday, December 28, 2016 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Recommendations for RECOVERY options
NTAC:3NS-20
We had a situation with a bad cable that resulted in a huge performance
impact due
NTAC:3NS-20
We had a situation with a bad cable that resulted in a huge performance impact
due to the default way that z/OS (we are at 1.13) handles error recovery on
Ficon paths.
The symptoms were many (thousands) of IOS050I messages in the task's joblog,
followed by an IOS450E message, which
received this message in error, please
notify us immediately by reply email so that we may correct our internal
records. Please then delete the original message (including any
attachments) in its entirety. Thank you
-Original Message-
From: "James Peddycord" <j...@ntrs.com>
NTAC:3NS-20
We have a FIRECALL process now, but it's automated.
The vaulting process has taken the place of this FIRECALL process for
most applications teams. The systems programmers don't need to get a
FIRECALL ID to update SYS1 datasets. We only need them when working with
datasets that we
NTAC:3NS-20
Our company is undergoing a project to 'protect privileged access' by using a
password vaulting product. We have been doing this for quite some time for
applications teams who require higher levels of access to production datasets
for problem resolution, installs, etc.
The way it
NTAC:4UC-11
While investigating an issue, we noticed some variation in ping times from an
RHEL 6 (on z/VM 6.2) to a z/OS 1.13 LPAR on the same CEC, using a shared 10G
OSA.
Times for 1000 pings:
1000 packets transmitted, 1000 received, 0% packet loss, time 999056ms
rtt min/avg/max/mdev =
11 matches
Mail list logo
