Agreed.Thanks all for your input.
Frank M. Ramaekers Jr.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Rob van der Heij
Sent: Wednesday, September 08, 2010 4:29 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PROP RTABLE and
On Wed, Sep 8, 2010 at 10:59 PM, Tom Huegel wrote:
> But will this help Frank get started?
I would think so. I took the effort of actually coding the RTABLE and
showed that it works, and I pointed out the difference with his RTABLE
(that his original post wanted the full 80 chars to consist only
But will this help Frank get started?
On Wed, Sep 8, 2010 at 1:37 PM, Rob van der Heij wrote:
> On Wed, Sep 8, 2010 at 10:05 PM, Frank M. Ramaekers
> wrote:
>
> > So, using Start of 1 and end of 80 seems that it would scan positions 1
> to
> > 80 for the string specified (comparison text).
>
>
On Wed, Sep 8, 2010 at 10:05 PM, Frank M. Ramaekers
wrote:
> So, using Start of 1 and end of 80 seems that it would scan positions 1 to
> 80 for the string specified (comparison text).
Sure, that's for the 'arbchar-like' matching in $HCPCRC8082I$ which
means that it should be anywhere in those
gt;
>
>
>
>
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
> Behalf Of Rob van der Heij
> Sent: Wednesday, September 08, 2010 2:31 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: PROP RTABLE and HCPCRC
Rob van der Heij
Sent: Wednesday, September 08, 2010 2:31 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PROP RTABLE and HCPCRC8082I
On Fri, Sep 3, 2010 at 5:32 PM, Frank M. Ramaekers
wrote:
>
> I can't seem to get HCPCRC8082I entry in PROP RTABLE to work. I've
used message cla
Wish PROP would record the "type" in the log files.
Frank M. Ramaekers Jr.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Mike Walter
Sent: Wednesday, September 08, 2010 2:55 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject
gt;
>
>
>
> "Frank M. Ramaekers"
>
> Sent by: "The IBM z/VM Operating System"
> 09/08/2010 02:14 PM
> Please respond to
> "The IBM z/VM Operating System"
>
>
>
> To
> IBMVM@LISTSERV.UARK.EDU
> cc
>
> Sub
ot;
Sent by: "The IBM z/VM Operating System"
09/08/2010 02:14 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: PROP RTABLE and HCPCRC8082I
I've tried 1-7 for the message type and I cannot trap it (for some
reason).
On Fri, Sep 3, 2010 at 5:32 PM, Frank M. Ramaekers
wrote:
>
> I can’t seem to get HCPCRC8082I entry in PROP RTABLE to work. I’ve used
> message class 1-3 and start column of 1 and end column of 80 to try to get
> this to work.
>
>
>
> Anyone see anything wrong?
I think
IBMVM@LISTSERV.UARK.EDU
Subject: Re: PROP RTABLE and HCPCRC8082I
On Wed, Sep 8, 2010 at 9:02 PM, Frank M. Ramaekers
wrote:
>
> Tried changing it from "TELL MAINT" to "TELLMAIN" (for an EXEC that invokes
> both TELL MAINT and MSG MAINT). Still can't get it to work.
>
&
On Wed, Sep 8, 2010 at 9:02 PM, Frank M. Ramaekers
wrote:
>
> Tried changing it from “TELL MAINT” to “TELLMAIN” (for an EXEC that invokes
> both TELL MAINT and MSG MAINT). Still can’t get it to work.
>
> (I already have a similar EXEC that works.)
You sure it's a type "1" message and not "3"
erating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Kris Buelens
Sent: Friday, September 03, 2010 2:25 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PROP RTABLE and HCPCRC8082I
And, I hope you have your own TELL EXEC on OPERATOR's 191 disk: the
normal TELL EXEC will not forward the m
ptember 03, 2010 10:49 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PROP RTABLE and HCPCRC8082I
try a '/' at the end of the message .. also for testing at least leave
the 'type' column blank. and I don't know for sure, but I always right
justify my start and end columns.
And, I hope you have your own TELL EXEC on OPERATOR's 191 disk: the normal
TELL EXEC will not forward the message that PROP intercepts to MAINT. PROP
passes other argulents to the action routine (TELL in your case) and it
places the message text and the "parameter" (here MAIN
try a '/' at the end of the message .. also for testing at least leave the
'type' column blank. and I don't know for sure, but I always right justify
my start and end columns.
On Fri, Sep 3, 2010 at 8:32 AM, Frank M. Ramaekers wrote:
> I can’t seem to get HCPCRC8
I can't seem to get HCPCRC8082I entry in PROP RTABLE to work. I've used
message class 1-3 and start column of 1 and end column of 80 to try to
get this to work.
Anyone see anything wrong?
* --- --- -- --
> If those syslog levels are data in the linux message, then you can
> filter on them like filtering on any other character string. If the
> syslog levels are not in the data, no, you cannot filter.
Couldn't you use /etc/syslogd.conf to write only the levels you want to
/dev/console?
> > The sy
If those syslog levels are data in the linux message, then you can
filter on them like filtering on any other character string. If the
syslog levels are not in the data, no, you cannot filter.
If necessary, you could set up a separate svm, each running PROP, each
being the recipient of a
Issued: Error! Unknown document property name. iii
Hi Listers,
Is there a way of filtering Linux messages using PROP such that only those with
given Linux syslog levels are displayed on the z/VM console?
The "Getting Started with Linux on System z" manual shows how to
cc
System
Re: PROP question
10/08/2009 04:28
OPSVM: isn't that the logical operator? If PROP were to intercept "logical
operator not logged on" and maybe pass that to the logical operator (as it
isn't filtered by the RTABLE), one'd have an endless loop.
2009/10/8 Jihad K Kawkabani
> Greetings all,
> I cann
Greetings all,
I cannot seem to get PROP to react to a message:
The message appears in the log as follows: 09/10/08 15:02:12 userid
VMNODE: HCPCQU045E OPSVM not logged on
I have coded in the RTABLE the following:
|...+1+2+3+4+5+6+7
> At his point, CP, bloodlust sated, settles down to watch over his
harem of
> virtual machines, secure in the knowledge The Operator will maintain
order
> in the universe. (Sorry - it's "VM Week" on the Discovery Channel.)
> Alan Altmark
> z/VM Development
> IBM Endicott
Lions and tigers and bea
Find the spooled console: CP collects everything, from the first message on,
that is, even from before the spool is actually open. It should reveal
every LOGON/LOGOFF of OPERATOR etc.
2008/7/18 Scott Rohling <[EMAIL PROTECTED]>:
> :-) I enjoyed the apt metaphors, Alan...
>
> Thanks to Kris, Th
On Fri, Jul 18, 2008 at 4:32 PM, Alan Altmark <[EMAIL PROTECTED]> wrote:
> (Sorry - it's "VM Week" on the Discovery Channel.)
You made my week, Sir ! Too bad it's already friday...
:-) I enjoyed the apt metaphors, Alan...
Thanks to Kris, Thomas, and Alan for their suggestions.. I'll work with the
customer to try and determine what the real scenario might have been, as
there is some confusion there. I was also give a training session on this
system and doing some unnatura
On Friday, 07/18/2008 at 10:00 EDT, Kris Buelens <[EMAIL PROTECTED]>
wrote:
> When the operator logs off for some reason, the first user logging on
> with CLASS A becomes "system operator". Including a CP SET SYSOPER
> OPERATOR in the PROFILE EXEC of OPERATOR is handy indeed: it makes
> that an
The SET SYSOPER command should not affect the starting of PROP **it
will not cure the problem you are seeing.**
When z/VM is IPLed, it will autolog the "system operator" (whose
userid is indicated in SYSTEM CONFIG).
The CP directory can instruct your operator to IPL CMS
Then its PROFIL
Thanks -- we are suspecting that perhaps OP1 was SYSOPER, and I'm going to
have my customer put SET SYSOPER OPERATOR in both OPERATOR and OP1 PROFILE
EXEC. On the OP1 id - I'm also going to put the following in if OPERATOR
is not logged on:
'XAUTOLOG OPERATOR SYNCH'
'SET SYSOPER OPERATOR'
We'l
ROTECTED]
Behalf Of Scott Rohling
Sent: Friday, July 18, 2008 8:11 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: PROP not running on OPERATOR after REIPL
Seeing something a bit strange and wondering if anyone has any insight. =
When doing a SHUTDOWN REIPL (issued from the OP1 userid), we get the
fol
ommand. This occurs only if the system operator was not
> logged onto the primary system console at the time the system failure or
> SHUTDOWN REIPL occurred.
>
> OPERATOR was running disconnected when the reipl occurred. The result is
> that PROP is no longer running on OPERATOR when
operator was no
t
logged onto the primary system console at the time the system failure or
SHUTDOWN REIPL occurred.
OPERATOR was running disconnected when the reipl occurred. The result is
that PROP is no longer running on OPERATOR when the system reipls as it
appears the PROFILE EXEC for
I have been able to send selected messages through an EXEC via UDP to a
SYSLOGD server. Now I would like to send ALL messages through this exec
before the messages are processed/filtered by the rest of the PROP/PERFTK
filtering processes. Is there an exit point in either PROP or PERFTK for
I think Alan is correct. (Of course, I've been trained to believe that is
always the case.)
Mary Ellen Carollo
z/VM Development
No, it is not in the current definitions.
Can AUTORESTART be added to a device without bouncing the
stack? (it is a production system...)
Shimon
Original message
>Date: Mon, 5 May 2008 18:20:18 -0400
>From: Alan Altmark <[EMAIL PROTECTED]>
>Subject: Re: PROP
On Monday, 05/05/2008 at 10:32 EDT, Shimon Lebowitz <[EMAIL PROTECTED]>
wrote:
> Yes, a manual restart does help.
> I log in through a different connection and do
> IFCONFIG SGLAN UP
>
> That is what I want PROP to do too.
I could be mistaken (maybe Mary Ellen or Miguel can
Shimon,
I write VM:Operator macroes instead of PROP execs but this looks as if two
routines are needed.
The first would key off the DTCOSD309W message and set a session globalv
variable with the timestamp
The second would key of the DTCQDI001I message to check the time stamp in the
session
Yes, a manual restart does help.
I log in through a different connection and do
IFCONFIG SGLAN UP
That is what I want PROP to do too.
Original message
>Date: Mon, 5 May 2008 08:38:04 -0400
>From: Alan Altmark <[EMAIL PROTECTED]>
>Subject: Re: PROP restart of OSA
B500
> 06:37:34 DTCQDI001I QDIO DEVICE OSA-B5 DEVICE NUMBER B502:
> 06:37:34 DTCQDI007I DISABLE FOR QDIO DATA TRANSFERS
>
> I would like to prepare a routine to be triggered when these
> messages are seen by PROP. My problem is that the message
> lines which describe a problem (
be triggered when these
messages are seen by PROP. My problem is that the message
lines which describe a problem ('stop lan', 'shutting down',
'disable') do not include the device address or link name, and the
lines with the device do not mention the problem, but
If you're interested in additional functions that PROP doesn't provide, I
BM
Operations Manager for z/VM may fit the bill. For Tom's specific questio
n,
Operations Manager allows you to define a group of users and then apply a
rule to that group. The group definition suppo
I don't think you can use an * in the userid field. As a bypass, code an
exec as action routine and leave the userid field blank, your exec can then
test the userid.
Or, guessing you want to capture all SCIF messages of the LINUX servers, run
a special PROP server to which you route all
O NOT DISPLAY MESSAGES FROM THE FOLLOWING MACHINES
* --- --- --
LINUX*
i.e I can't specify a userid with a prefix.
What I wanted to do was to tell PROP that all LINUXxx machines
Title: RE: Any way to stop PROP from logging 'select messages'?
Thanks for the tip, I would have missed that until later on.
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On
Behalf Of Alan Altmark
Sent: Monday, November 06, 2006 1
On Monday, 11/06/2006 at 10:40 CST, "Huegel, Thomas" <[EMAIL PROTECTED]>
wrote:
> On further analysis it looks like DMSPOA uses standard CMS I/O ie.
FSWRITE .. I
> think a little SVC 202 trap might be the easiest and safest, and most
flexiable
> way around this.
FSREAD (RDBUF) and FSWRITE (WR
Title: RE: Any way to stop PROP from logging 'select messages'?
Don't have HL Assembler here. Anyway I think I would make my mods to DMSPOP (PROP Mainline) or DMSPOA (Action routine that does the logging). The messages themselves are absolutly useless. They give a GRAF
a security audit.
Mike Walter
Hewitt Associates
"Huegel, Thomas" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System"
11/03/2006 02:43 PM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Any
On Friday, 11/03/2006 at 02:43 CST, "Huegel, Thomas" <[EMAIL PROTECTED]>
wrote:
> Does that stop PROP from writting to the log file?
No. LOGGING OFF is the only way to stop a message from being logged. You
could define your own action routine that handles logging for you.
I'm not aware of any method for preventing writing to the log file.
- Tom.
At 12:43 PM 11/3/2006, you wrote:
Alan,
Does that stop PROP from writting to the log file?
My problem is that I have an application that does 10-15K DIAL/DROP a day.
That really is a waste.
Tom
Tom Cl
Title: RE: Any way to stop PROP from logging 'select messages'?
Alan,
Does that stop PROP from writting to the log file?
My problem is that I have an application that does 10-15K DIAL/DROP a day.
That really is a waste.
Tom
-Original Message-
From: The IBM z/VM
On Friday, 11/03/2006 at 01:52 CST, "Huegel, Thomas" <[EMAIL PROTECTED]>
wrote:
> Is there a way to stop PROP from logging certain messages?
Update PROP RTABLE with something like:
*--- -- -- -
* FILTER OUT LOGON, LOGOF
Title: Any way to stop PROP from logging 'select messages'?
Hi All,
Is there a way to stop PROP from logging certain messages?
Or even better to stop messages 'DIALED and DROP' from being generated?
Thanks
Tom
__
53 matches
Mail list logo
