>>> On 7/27/2012 at 01:26 PM, Michael MacIsaac wrote:
> Nice test case! I modified it a bit :))
I have two SLES10 SP4 systems. One is on a fairly loaded box, and one is on a
fairly idle box. On the loaded box, the failure rate of the chccwdev -e
command was fairly high, even with a 2 second
Dear all,
I can confirm that the udev settle is returning always with zero. I have
the timeout set to even to 60 sec and an exit if the device node is
available. And that is stlll not enough because udev exits. Without exit I
had set the timeout to 30 secs. Only running the loop two times the chan
I've not done much, but my first step was:
getfacl -Rst . | tr '\n' ' ' | { sed 's/#/\n#/g'; echo; } | cat
In a small test in the current directory, I had two files with ACLs in ~/z.
When I ran the above in ~, the output looked like:
# file: z/sort.info USER tsh009rw- user tss
Over time, some of my systems have ACLs scattered around and I'm looking for a
way to get a report of which users and groups have ACLs set across a file
system. The closest I got so far is getfacl -Rst / , but it still gives a lot
of detail to sift through. Are there any utilities that will disp
> I believe that's the piece that's missing (for most people). I can easily
> reproduce the problem on my SLES11 SP2 system with this script:
> vmcp define vfb-512 302 2000
> date +%H:%M:%S.%N
> chccwdev -e 0.0.0302
> mkswap /dev/disk/by-path/ccw-0.0.0302-part1
Yeah, that's pretty much guaranteed
>>> On 7/27/2012 at 01:26 PM, Michael MacIsaac wrote:
> I never got the chccwdev to fail.
If you did the test on SLES11 or later, I don't think that command will fail
since it uses /proc/cio_settle.
Mark Post
--
For LINUX-39
Mark,
> I can easily reproduce the problem on my SLES11 SP2 system with this
script:
> ...
Nice test case! I modified it a bit :)) I never got the chccwdev to fail.
I did see the mkswap fail regularly. Then I randomly added a "udevadm
settle" after the chccwdev -e. Every time the udevadm settl
very true. Executive or near to executive level sponsorship is key.
Can't progress much without it.
David Kreuter
Original Message
Subject: Re: z/Linux and z/OS
From: OAKES Roger * ETS
Date: Fri, July 27, 2012 12:37 pm
To: LINUX-390@VM.MARIST.EDU
David, we've been running Linu
We have been running several z/OS LPARS and several z/VM LPARS alongside of
them in production for a few years.
The zVM hosts RHEL.
They are currently running on a z114 (they were on a z10 BC before that)
We have not considered running z/OS under z/VM.
As others have said, running zVM makes life mu
On Friday, 07/27/2012 at 11:33 EDT, Sebastian Ott
wrote:
> The process of setting the device online involves generic path
> verification work done by the Common IO Layer and device specific
> online processing done by the device driver (DASD in this case). Once
> the DASD driver finished its work
David, we've been running Linux on Z for quite a while, since about 2003 or so.
Tech management read about the IFL processor for the z/800, IBM made them a
heck of a deal and we had someone step up and offer to support Linux and VM so
we were off and running.
Now we're floundering a bit. Te
> We have a set of scripts that Setup the WHOLE multipath SAN disk for us.
> From the chccwdev, zfcp_*, to fdisk
> and format and multipath setup and mount (Yes the WHOLE thing). We
> have found by placing sleep for 15 seconds between commands , especially
> the hardware level ones, increased our
>>> On 7/27/2012 at 11:15 AM, Sebastian Ott wrote:
> Once
> the DASD driver finished its work and created a block device, userspace
> is informed about this via uevents. After that chccwdev returns. The
> only thing that's missing now is udev creating a device node and that's
> covered via udev s
>Once the DASD driver finished
> its work and created a block device, userspace is informed about this via
> uevents. After that chccwdev returns. The only thing that's missing now is
> udev creating a device node and that's covered via udev settle.
Thanks for the walkthrough. The problem appears
We have a set of scripts that Setup the WHOLE multipath SAN disk for us.
>From the chccwdev, zfcp_*, to fdisk
and format and multipath setup and mount (Yes the WHOLE thing). We have
found by placing sleep for 15 seconds between commands , especially the
hardware level ones, increased our reliabil
On Fri, 27 Jul 2012, David Boyes wrote:
> > On which distro do you have problems with chccwdev?
> > [snip]
> > ..which appears to work fine.
>
> It's not a distribution issue; it's a timing-dependent issue that has to do
> with how quickly your hardware responds. Your script will work *most* of th
> On which distro do you have problems with chccwdev?
> [snip]
> ..which appears to work fine.
It's not a distribution issue; it's a timing-dependent issue that has to do
with how quickly your hardware responds. Your script will work *most* of the
time -- except when it doesn't.
Easy way to rep
Good morning again and a happy Friday to all.
I wanted to thank everyone who responded to my post yesterday. This listserv
looks like a tremendous resource and repository of z/Linux and mainframe
knowledge. I'm sure I'll be back soon!
David Spring
Social Security Administration
DCS/OTSO/DMSS/
On Thursday, 07/26/2012 at 05:43 EDT, Ingo Adlung
wrote:
> I wouldn't go that far to state that IBM recommends a production
> environment to be z/VM based.
In fact, it would be better to say that IBM no longer recommends against
running production z/OS on z/VM, now letting business factors rather
On Thu, 26 Jul 2012, David Boyes wrote:
> A week or two back, someone (I think it was Florian Bilek) asked why there
> was a delay between invoking chccwdev and the device becoming available, and
> whether there was an option or command that would exit only when the device
> was actually availab
20 matches
Mail list logo
