Schuh
--
*From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
Behalf Of *Mike Walter
*Sent:* Wednesday, August 29, 2007 2:30 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: OPERATOR Consoles
Yep, again. See Chapter 10.
Mike Walter
That would be a nice addition to the DOWNLOAD page.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Kris Buelens
Sent: Thursday, August 30, 2007 1:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: OPERATOR Consoles
My customer has 18 VM systems
: OPERATOR Consoles
My customer has 18 VM systems...
A problem with managing many VM systems is that operators need to see
that there is a problem. Problems can go away automatically too (e.g. a
queue on a RSCS link). We had a central VM:OPER console where problems
got listed as HOLDMSG
A poor man's alternative to VM:Operator, probably for a smaller number
of systems and with lesser capabilities, would be the Programmable
Operator facility that comes with VM. I don't want to start an argument
here. I know that VM:Operator would do a great job but if you are only
talking
will be made.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Jim Bohnsack
Sent: Thursday, August 30, 2007 10:28 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: OPERATOR Consoles
A poor man's alternative to VM:Operator
Buelens
*Sent:* Wednesday, August 29, 2007 11:48 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: OPERATOR Consoles
My customer has 18 VM systems...
A problem with managing many VM systems is that operators need to see that
there is a problem. Problems can go away automatically too (e.g. a queue
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: OPERATOR Consoles
It's not a product, it is named VMSTAT.
2007/8/30, Schuh, Richard [EMAIL PROTECTED]:
That sounds nice. What is the name of your product? :-)
Regards,
Richard Schuh
From: The IBM z/VM Operating
--
*From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
Behalf Of *Kris Buelens
*Sent:* Thursday, August 30, 2007 10:45 AM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: OPERATOR Consoles
It's not a product, it is named VMSTAT.
2007/8/30, Schuh, Richard [EMAIL PROTECTED
In the not too distant future, we will possibly have VM systems
scattered almost as widely as we have datacenters. What products are
available that would allow the operations of these systems to be handled
from a single location, if such exist? For example, can VM:Operator be
used across a span of
.
_
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, August 29, 2007 4:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: OPERATOR Consoles
In the not too distant future, we will possibly have VM systems
scattered almost as widely
@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
OPERATOR Consoles
In the not too distant future, we will possibly have VM systems scattered
almost as widely as we have datacenters. What products are available that
would allow the operations of these systems to be handled from a single
@LISTSERV.UARK.EDU
Subject: Re: OPERATOR Consoles
Sure. If you can logon to the system, VM:Operator can have a console
there. The OPERATOR id can be anywhere. Authorized users can be defined
to logon and run VMYIAMOP to get a copy of the console. The definition
of the user within VM:Operator says what screens
Yep, again. See Chapter 10.
Mike Walter
- Original Message -
From: Schuh, Richard [EMAIL PROTECTED]
Sent: 08/29/2007 04:30 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: OPERATOR Consoles
I was thinking more along the lines of operating all systems from one
terminal.
Regards
Subject: Re: OPERATOR Consoles
Yep, again. See Chapter 10.
Mike Walter
- Original Message -
From: Schuh, Richard [EMAIL PROTECTED]
Sent: 08/29/2007 04:30 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: OPERATOR Consoles
I was thinking more
Thanks for all the responses. Apologies for my tardiness in responding...
been too busy checking out all the suggestions!
Eginhard Jaeger wrote:
- Nothing should prevent you from entering the same PROCESS
definition multiple times, and have it processed multiple times.
Another possibility
...
With the Performance Toolkit, the last match in FCONX $PROFILE
is used when processing messages, so again, there is no possibility
of multiple entries for the same message.
...
PerfKit's logic should be different:
- 'FC PROCESS' definitions made for a specific output line type
should
Hello Fred,
I hope that you (eventually) find this useful, but I'm going to
unhelpfully start by suggesting that you take a step back and delete from
your mind the idea that VM has a, console.
The VM paradigm is fundamentally different to the OS paradigm - in VM, an
y
appropriately privileged
Back in the mid-1990s, I wrote some EXECs to extend the capability of PROP
to allow multiple logical operators to interact with a single PROP. My
colleague Jim Vincent includes this information in his SHARE session
entitled Automated Linux Guest Monitoring on z/VM using PROP (Session
9136) in
Fred,
I have come up a set of REXX programs that with the help of
PIPESERV maintain a console log that can be redisplayed as in VSE. The
REXX EXEC that displays the log files also allows for the sending of
commands to the OPERATOR machine. This all uses the security that is
built into
If what you're trying to do is have multiple terminals displaying the
operator console (and you have PERFKIT), try using the APPC interface
and the FCONAPPC exec from another userid and run PERFKIT with no
monitoring active in the OPERATOR userid. That should let you go into
basic mode in PERFKIT,
Hi folks,
How do you set up multiple consoles in z/VM?
I've got PROP implemented and use the Performance Toolkit to manage the
console display of the Logical Operator. This works well... I just want
more of them!
In trolling the IBMVM archives, I've seen several references to setting up
21 matches
Mail list logo
