change the following message may
be issued by RMFGAT:
RMFGAT ERB307I III: MONITOR III DATA GATHERER ERB3GINI.
INTERFACE BPX1SDD FAILED. RETURN CODE: REASON CODE:
.
ERB3GINI issues USS service BPX1SDD to dub the RMFGAT as a
permanent process. It is possible
Subject: Re: ERB307I III: MONITOR III DATA GATHERER ERB3GINI. INTERFACE
BPX1SDD FAILED. RETURN CODE: REASON CODE:
If they check for a non-zero return value from BPX1SDD, then this would
be the expected behaviour when the required setting was already in
effect. A return value of -1 from
On Thu, 13 Mar 2008 21:54:31 -0400, Knutson, Sam wrote:
If you observe daylight savings time, run RMF Monitor III, and make the
time change automatically using an ETR (or not) I would appreciate it if you
could check and see if you had this happen and contact me.
Tried it on the sandbox:
On Thu, 13 Mar 2008 21:54:31 -0400, Knutson, Sam [EMAIL PROTECTED] wrote:
At the time change here an anomaly occurred in RMF.
I opened a PMR on this but we have only the WTO message which occurred on
every system in the Sysplex when the ETR changed the time.
There are no hits for the ERB307I
On Thu, 13 Mar 2008 21:54:31 -0400, Knutson, Sam wrote:
At the time change here an anomaly occurred in RMF.
I opened a PMR on this but we have only the WTO message which occurred
on every system in the Sysplex when the ETR changed the time.
(snip)
It would be useful if someone else also had
On Fri, 14 Mar 2008 08:42:42 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:
Our procedures say RMF III (RMFGAT) has to be recycled for a time change
(either backwards or forwards). This was from past experience and was
also documented in the Redbook S/390 Time Management and IBM 9037
Sysplex
Got the same thing here, on all 3 LPARs. z/OS 1.7, 3 monoplexes, 2 on STP, 1
manual timezone change.
Knutson, Sam [EMAIL PROTECTED] 3/13/2008 9:54 PM
At the time change here an anomaly occurred in RMF.
I opened a PMR on this but we have only the WTO message which occurred on every
system in
Hi Mark,
We recycled last year because of OA19062 but having the PTFs applied did
not include a recycle of RMF in our procedures this year. I don't know
when it changed but it has been a while I thought.
APAR Identifier .. OA19062 Last Changed 07/02/02
RMF MONITOR I OR RMF
If they check for a non-zero return value from BPX1SDD, then this would
be the expected behaviour when the required setting was already in
effect. A return value of -1 from BPX1SDD is a bad result.
BPX1SDD is supposed to return the previous dub setting so, if the
previous call to BPX1SDD was
At the time change here an anomaly occurred in RMF.
I opened a PMR on this but we have only the WTO message which occurred on every
system in the Sysplex when the ETR changed the time.
There are no hits for the ERB307I BPX1SDD with return code
Reason found by me or Level-2. ERB3GINI
10 matches
Mail list logo