Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DFHSM message ARC0026E - EOV error on JOURNAL.

611 views
Skip to first unread message

John McKown

unread,
Apr 15, 2013, 9:15:24 AM4/15/13
to
I've already entered a service request on IBM link about this, but
thought I'd ask here as well. On Saturday, we got the DFHSM message:

*ARC0026E JOURNALING DISABLED DUE TO EOV ERROR ON 852
ARC0026E (CONT.) JOURNAL. MIGRATION, BACKUP, FRBACKUP, DUMP, TAPECOPY,
ARC0026E (CONT.) TAPEREPL, RECYCLE, ARECOVER, AUDIT, AND EXPIREBV HELD.
ARC0020I ******************************

This has happened before. This time, it appears that in addition to
the above, that every job which issues a request to DFHSM via SVC-109,
code x'18' went into a WAIT (SVC 1) on some ECB which was never
POSTed.

Has anybody seen this message before? How did you eliminate it? I have
done what the book said: stop all DFHSM; rename old JOURNAL; all new
JOURNAL data set;S DFHSM,EMERG=YES on one system; wait for it to come
up; S DFHSM on second system. We have two systems sharing all the
DFHSM data sets in a __basic__ sysplex (not parallel, we won't get a
ICF engine).

--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

Staller, Allan

unread,
Apr 15, 2013, 9:28:18 AM4/15/13
to
When was the last time you successfully ran a BACKVOL CDS command?

<snip>
*ARC0026E JOURNALING DISABLED DUE TO EOV ERROR ON 852 ARC0026E (CONT.) JOURNAL. MIGRATION, BACKUP, FRBACKUP, DUMP, TAPECOPY, ARC0026E (CONT.) TAPEREPL, RECYCLE, ARECOVER, AUDIT, AND EXPIREBV HELD.
ARC0020I ******************************

This has happened before. This time, it appears that in addition to the above, that every job which issues a request to DFHSM via SVC-109, code x'18' went into a WAIT (SVC 1) on some ECB which was never POSTed.

Has anybody seen this message before? How did you eliminate it? I have done what the book said: stop all DFHSM; rename old JOURNAL; all new JOURNAL data set;S DFHSM,EMERG=YES on one system; wait for it to come up; S DFHSM on second system. We have two systems sharing all the DFHSM data sets in a __basic__ sysplex (not parallel, we won't get a ICF engine).
</snip>

Lizette Koehler

unread,
Apr 15, 2013, 9:35:38 AM4/15/13
to
John,

Did you ask this question back in 2009? At least I think it was you.

In Infocenter this link has an answer to your question

http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib
m.zos.r12.arcf000%2Fcase1.htm

Do you have the journal dumped frequently? Do you have a small journal? Or
really large?

Basically what Allen said - BACKVOL CDS. When do you run this in HSM? You
should have a daily dump of the CDS datasets and the Journal should be part
of that. Check to see when your last run of this command occurred and see
if there were any errors.

Lizette

Miklos Szigetvari

unread,
Apr 15, 2013, 9:37:20 AM4/15/13
to
Hi

I think we had this before, if the MIGRATION etc. HELD, the requesters
are in wait as long as it is not solved . After some JOURNAL repair,
here everything worked normal, but it has happened a few years ago :
IEC031I D37-04,IFG0554P,DFHSM,DFHSM,JOURNAL,026A,CICS52,SYSPLEX.DFHSM.JR
NL.ACTUAL
ARC0020I ******************************
ARC0026E JOURNALING DISABLED DUE TO EOV ERROR ON 764
ARC0026E (CONT.) JOURNAL. MIGRATION, BACKUP, FRBACKUP, DUMP,
TAPECOPY,
ARC0026E (CONT.) TAPEREPL, RECYCLE, ARECOVER, AUDIT, AND
EXPIREBV HELD.


--
Kind regards, / Mit freundlichen Gr��en
Miklos Szigetvari

Research& Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.s...@isis-papyrus.com
Info: in...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

John McKown

unread,
Apr 15, 2013, 9:38:10 AM4/15/13
to
last BACKVOL CDS was at 17:33:09 Saturday. The first ARC0026E message
that I can find in either SYSLOG is at 18:00:30 on Saturday, or about
30 minutes later.
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

John McKown

unread,
Apr 15, 2013, 9:54:33 AM4/15/13
to
I don't think that was me. But my memory is not accurate that far in
the past. I will double check that the BACKVOL CDS which was done
about 30 minutes prior to this EOV error message did not get any
errors written to the SYSLOG.

Thanks for the link. I just "slipped in" a quick shutdown of DFHSM on
all systems and did an EXAMINE on the MCDS and BCDS. No problems
found, so the article didn't give me a fix. I do appreciate it,
however.

On Mon, Apr 15, 2013 at 8:35 AM, Lizette Koehler
<star...@mindspring.com> wrote:
> John,
>
> Did you ask this question back in 2009? At least I think it was you.
>
> In Infocenter this link has an answer to your question
>
> http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ib
> m.zos.r12.arcf000%2Fcase1.htm
>
> Do you have the journal dumped frequently? Do you have a small journal? Or
> really large?
>
> Basically what Allen said - BACKVOL CDS. When do you run this in HSM? You
> should have a daily dump of the CDS datasets and the Journal should be part
> of that. Check to see when your last run of this command occurred and see
> if there were any errors.
>
> Lizette
>

Staller, Allan

unread,
Apr 15, 2013, 9:57:28 AM4/15/13
to
You might to review "DFSMShsm in a multiple-image environment" in the appropriate version of
DFSMShsm Implementation and Customization Guide.

You have not indicated if you are running primary and secondary dfHSM tasks. The guide specifically suggests this to prevent race conditions
during selected activities (migration, backup, recall, dump).

If all is as indicated unless some *really really* serious activity (migration, recall, backup) was going on, I would suggest a DASD error or JOURNAL
dataset too small. Review the size and/or move the JOURNAL dataset to another volume.

BTW, I have been running in the same configuration (multi-HSM, base SYSPLEX) since 2010 with no occurrence of this issue.

Feel free to contact me off list if necessary...

HTH,

<snip>

John McKown

unread,
Apr 15, 2013, 10:03:08 AM4/15/13
to
The journal may be a bit small. It's only 25 cylinders. I'll expand it ASAP.
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

0 new messages