On Tue, 25 Jan 2011 17:03:59 -0500 (EST), Alan Altmark wrote:
> The description of DISCONNECT_TIMEOUT is a little vague in that it talks
> about "forced disconnect". That situation occurs when
> 1. You get an I/O error on local non-SNA 3270 device (e.g. TEST/NORMAL,
> chpid pull);
> 2. You sever
On Tuesday, 01/25/2011 at 11:46 EST, "Schuh, Richard"
wrote:
> Are you sure about that? Any posted read that is not responded to will
get a
> disconnected machine forced regardless of whether it is VM or CP read.
The
> forced disconnect is in response to terminal errors during I/O and is
r
er systems.
>
>
> Regards,
> Richard Schuh
>
>
>
>
> --
> *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On
> Behalf Of *Kris Buelens
> *Sent:* Tuesday, January 25, 2011 12:34 AM
>
> *To:* IBMVM@LISTSERV.UARK.EDU
> *
cannot speak to the earlier systems.
Regards,
Richard Schuh
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Kris Buelens
Sent: Tuesday, January 25, 2011 12:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Forced logoff by
01/24/2011 01:43 PM
Subject: Re: Forced logoff by SYSTEM?
Sent by:The IBM z/VM Operating System
> AND, if you connect to the *VMEVENT system service, you can be notified
> any time a guest goes into "disconnect timeout pending" state
Quick question: how is the
Logically the Virtual Machine would be in VM READ.
But in the VM/XA branch of VM -on which z/VM is based- any VM READ of a
disconnected user without secondary user gets translated in a CP READ. I
find this a bug, VM/SP and VM/HPO did it right. Without setting a secondary
user on it, one cannot ev
The OP (that's me) has mentioned opening a PMR
over the fact that PERFSVM did in fact abend.
I thought that after creating a VMDUMP, the virtual
machine would be in a CP READ, but I guess I misunderstood.
Shimon
On Tue, Jan 25, 2011 at 4:37 AM, Stephen Powell wrote:
>
>
> What probably happened
On Mon, 24 Jan 2011 12:14:18 -0500 (EST), John Franciscovich wrote:
> On Sun, 23 Jan 2011 20:38:38 -0500 (EST), Stephen Powell wrote:
>> The most common cause for a FORCED LOGOFF BY SYSTEM is that the
>> virtual machine went into a VM READ. If a disconnected virtual
>> machin
On Monday, 01/24/2011 at 01:43 EST, David Boyes
wrote:
> > AND, if you connect to the *VMEVENT system service, you can be
notified
> > any time a guest goes into "disconnect timeout pending" state
>
> Quick question: how is the data field in the VMEVENT message formatted?
There's
> a layout f
> AND, if you connect to the *VMEVENT system service, you can be notified
> any time a guest goes into "disconnect timeout pending" state
Quick question: how is the data field in the VMEVENT message formatted? There's
a layout for parsing the TRGCLS, but not the data. Is it literally
userid","co
On Monday, 01/24/2011 at 01:24 EST, John Franciscovich
wrote:
> > The most common cause for a FORCED LOGOFF BY SYSTEM is that the
> > virtual machine went into a VM READ. If a disconnected virtual
> > machine goes into a VM READ, CP sets a timer. By default, this
> > t
> The most common cause for a FORCED LOGOFF BY SYSTEM is that the
> virtual machine went into a VM READ. If a disconnected virtual
> machine goes into a VM READ, CP sets a timer. By default, this
> timer is 15 minutes. I'm not sure if this is configurable or not,
> I haven
Thank you!
There was a dump, and I did open a call.
Shimon
On Sun, Jan 23, 2011 at 9:28 PM, Kris Buelens wrote:
> My guess is that it abended. It doesn't write that event in its log ...
> (obviously).
> Look in the spool for a dump file from PERFSVM, and you'll have no other
> choice then to se
it ABENDed and went into a disabled wait, that should be visible
> in its console, I'd think...
The most common cause for a FORCED LOGOFF BY SYSTEM is that the
virtual machine went into a VM READ. If a disconnected virtual
machine goes into a VM READ, CP sets a timer. By default, this
ti
On Sun, Jan 23, 2011 at 3:21 PM, Doug wrote:
> Possibly one of your trends or history disks became full ..
Why would that cause LOGOFF BY SYSTEM? Userid might log itself off, but not BY
SYSTEM.
If it ABENDed and went into a disabled wait, that should be visible in its
console, I'd think...
--
On 1/23/2011 11:39, Shimon Lebowitz wrote:
Hi,
On Thursday (actually, it was just past midnight, Wednesday night),
PERFSVM was forced
off by SYSTEM, while running DSC as usual:
The operator log showed these lines:
00:51:51 USER DSC LOGOFF AS PERFSVM USERS = 66FORCED BY SYSTEM
00:51:51
My guess is that it abended. It doesn't write that event in its log ...
(obviously).
Look in the spool for a dump file from PERFSVM, and you'll have no other
choice then to send that to the support center.
2011/1/23 Shimon Lebowitz
> Hi,
> On Thursday (actually, it was just past midnight, Wednes
Hi,
On Thursday (actually, it was just past midnight, Wednesday night), PERFSVM
was forced
off by SYSTEM, while running DSC as usual:
The operator log showed these lines:
00:51:51 USER DSC LOGOFF AS PERFSVM USERS = 66FORCED BY SYSTEM
00:51:51 HCPMNI6245I The monitor IUCV path was abnormall
18 matches
Mail list logo
