Backup failure (CPF1EE7).
tho...@inorbit.com
Richard:
At first glance, it looks as if msgq(QSYSOPR) is in *DFT mode rather than
*HOLD. But you said you'd checked the *msgq... ? Certainly there are a number
of ways a message can get an automated reply. A job can be running
INQMSGRPY(*DFT or *SYSRPYL) or there could be something such as ROBOT
monitoring the queue.
Tom Liotta
In article <358693...@eds.com>,
rkn...@pcisys.net wrote:
>
> Ever since I did my Y2K clock change I have had problems with my
> backups. They keep failing.
>
> The backup requests another tape:
> "Load next tape volume on device TAP01. (C G) "
>
> Then the system automatically reply's to the message in the QSYSOPR
> message queue with "C". and since our backups are run unattended this is
> not good. the backup then fails. What use to happen (prior to clock
> change) was the notify message would sit in the qsysopr message queue
> until I would come in earily in the morning and take care of it. (as the
> second tape only runs a few minutes). I have looked at my qsysopr
> profile, the message queue, the backup jobs in OA, my system values
> (unless I am missing one somewhere). I browsed through the backup and
> recovery guides (basic/advanced) even.
>
> Does someone know what to look at to change the system from
> automatically replying to the notify messages in the qsysopr message
> queue? I haven't had a successful backup in three days now. Help Please.
>
> Thanks.
>
> Regards,
>
> --
>
> Richard Knechtel
> CENTROBE
> (an EDS company)
>
> (Systems Engineer/System Administrator)
> (Aspiring AS/400 GURU)
> (Aspiring Linux GURU)
> (Aspiring Visual Basic Programmer)
>
> The contents of this message express only MY opinion.
> This message does not necessarily reflect the policy or views of
> my employer, EDS. All responsibility for the statements
> made in this posting resides solely and completely with the
> ME.
> I Ex-Spaminate spammers!
> See US Code Title 47, Sec.227(a)(2)(B), Sec.227(b)(1)(C)
> and Sec.227(b)(3)(C).
>
>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Richard Knechtel
Richard Daniels wrote:
>
> Richard... I hope Frank's replies get things going there... If not, be sure to
> review the job log for the backup. There should be a clue there somewhere. Part of
> the prob may depend on which backup command is being used at the time of failure. If
> doing a SAVCHGOBJ, check to see if the 'reference date & time' are in conflict with
> an object that was used during the Y2K test.
>
> Call or Email me if you like.
>
> Dick Daniels
> WYNTH,Inc
>
> Richard Knechtel wrote:
> >
> > Ever since I did my Y2K clock change I have had problems with my
> > backups. They keep failing.
Well, My weekly backup ran last night and it ran fine except for the cpf
message I get once in a while:
*WEEKLY backup not successful or not complete (CPF1E68).
Job 120332/QSYSOPR/QEZBKTMWED completed normally on 06/17/98 at
02:21:19.
I get the CPF1E68 now and again but it's nothing to worry about from
what I have seen.
The problem is deffinatly when it needs another tape. we use DC6525
tapes for daily backups (525 meg) and 1.2 gig tapes for our weekly and
monthly. Since the backup ran ok last night this tells me that it was a
second tape issue. I am going to check out the items Frank pointed out
this AM.
Thanks,
Richard Knechtel
tho...@inorbit.com wrote:
>
> Richard:
>
> At first glance, it looks as if msgq(QSYSOPR) is in *DFT mode rather than
> *HOLD. But you said you'd checked the *msgq... ? Certainly there are a number
> of ways a message can get an automated reply. A job can be running
> INQMSGRPY(*DFT or *SYSRPYL) or there could be something such as ROBOT
> monitoring the queue.
>
> Tom Liotta
Well, I double checked the MSGQ and it was set to *NOTIFY (I thought
that this is what is was all along, maybe not. I change itto *HOLD) We
don't have ROBOT so I tossed that idea out. I will see what it does
tommorrow after I changed the Queue to *HOLD.
Thanks much Tom.
(Boy am I learning some things about the AS/400 I didn't know about
before, that I did.) :^)
Charles R. Pence
An FYI <may be of use>:
APAR= SA62229 SER= EZ PIN=5763SS1OA-079 MS MSGCPF1EE7
OSP-MSGCPF1EE7 UNEXPECTED ERROR OCCURRED DURING BACKUP WHEN
BACKUP IS INCOMPLETE AND NOT ALL OBJECTS SAVED
STAT= CLOSED DOC FESN0900721- CTID= RH2800 ISEV= 2
SB97/03/04 RC97/03/06 CL97/03/11 PD97/03/12 SEV= 2
PROBLEM SUMMARY:
Customer gets MSGCPF1EE7 Unexpected error occurred during back
when backup is incomplete because not all objects were saved.
Message does not inform user that QEZBACKUP job description
needs to be changed to obtain O/A BATCH backup JOBLOG.
PROBLEM CONCLUSION:
Operational Assistant backup support was designed to be error-
tolerant. The code attempts to complete as much of the backup
as possible when errors occur. Details from the informa-tion
that follows will be added to existing help panels and the
System Operation manual and/or other appropriate new manuals the
next time they are updated.
--------- BACKUP GUIDELINES -----------------------------------
JOB LOGS:
When the code was designed it was decided that only certain
messages in which the code could determine the cause of the
error would be returned to the end user.
This is the case for the CPF1EE7 message. An example of the
additional message information follows:
MESSAGE ID . . . . . . : CPF1EE7 SEVERITY .. . . . : 30
MESSAGE TYPE . . . . . : DIAGNOSTIC
MESSAGE . : UNEXPECTED ERROR OCCURRED DURING BACKUP.
CAUSE . . : AN ERROR OCCURRED DURING THE *MONTHLY BACKUP THE
PROGRAM COULD NOT DETERMINE THE CAUSE OF THE ERROR. THE PROGRAM
ATTEMPTED TO COMPLETE AS MUCH OF THE BACKUP AS POSSIBLE.
RECOVERY : USE F10 (IF AVAILABLE) OR THE DISPLAY JOB LOG
(DSPJOBLOG) COMMAND TO SEE THE MESSAGES IN THE JOB LOG FOR A
MORE COMPLETE DESCRIPTION OF WHAT WAS BACKED UP AND WHAT CAUSED
THE ERROR. CORRECT THE ERRORS AND TRY THE REQUEST AGAIN. YOU
MAY NEED TO CONTACT YOUR TECHNICAL SUPPORT PERSON TO SOLVE THE
PROBLEM.
If the command was entered from the command line <interactive
mode; for example: "RUNBCKUP BCKUPOPT(*MONTHLY)">, and an
unexpected error occurred during backup, the following message
would appear on the bottom of the panel:
"UNEXPECTED ERROR OCCURRED DURING BACKUP."
You could use the help function to see the additional message
information as shown above. Pressing F10 would show
you the detailed errors. Also, entering DSPJOBLOG on the
command line would show you the same information.
Running the same command in batch mode, (for example selecting
option 3 from the "RUN BACKUP" menu) would submit the same
command. The following message would appear on the bottom of
the panel if an error did or did not occur during processing:
"BACKUP JOB SUBMITTED."
You could use the help function to see the additional message
information as follows:
MESSAGE ID . . . : CPC1E61 SEVERITY .. . . . : 00
MESSAGE TYPE . . : COMPLETION
MESSAGE . .: BACKUP JOB SUBMITTED.
TECHNICAL DESCRIPTION .. : BACKUP WILL BE RUN AS A BATCH JOB
USING JOB DESCRIPTION QEZBACKUP/QGPL.
This message identifies the job description your job is using.
This example shows the default value shipped with the system and
if no changes were made on your system it will be used.
To determine if any errors occurred during backup jobs sub-
mitted as a batch job, it is necessary to look at the job log.
The QEZBACKUP job description is shipped with the following
values for Message Logging:
LEVEL . . . . . . . . . . . . . . . . . . . . : 4
SEVERITY . . . . . . . . . . . . . . . . . . . : 0
TEXT . . . . . . . . . . . . . . . . . . . . . : *NOLIST
and with
END SEVERITY . . . . . . . . . . . . . . . . . : 30
If this has not been changed on your system, then a job log
would be produced if an error is detected which has a severity
of 30 or greater. This is the case for our CPF1EE7, and CPF1E99
(unexpected error condition messages). This is true even if the
TEXT is set to *NOLIST as in our example above because a job log
is always produced if the end of job code is 20 or higher and
this example would meet that condition.
A message that is sent to advise that some, but not all, objects
were backed up is CPF1E68. It is shipped with a severity level
of 20. This was an intentional design decision in keeping with
our plan to complete as much of the backup as possible without
ending the job. Operational Assistant may invoke multiple save
commands. If an error is encountered during one of the save
commands, that particular command would end and Operational
Assistant backup would continue to the next save command (if one
exists). A flag is set to indicate something didn't complete
and the CPF1E68 message is sent. The low severity of the
CPF1E68 message will not force a a job log to be produced.
You must decide if you always want a job log produced. If you
would like the job log to always be created, regardless of the
severity of the error conditions, you could enter the following
command which will always force a job log to be produced:
"CHGJOBD QEZBACKUP LOG(4 00 *SECLVL)"
----------------------------------------------------------------
BACKUP EXIT PROGRAM:
Another method to force a job log is also available. You can
specify the name of your user program to call before the backup
begins and again after the backup is complete. This program
name is specified on the CHANGE BACKUP OPTIONS (CHGBCKUP) panel.
Details are in the System Programmer's Interface Reference
guide.
In your exit program, you can check the return code and if the
CP1E68 is returned, you can then add code to produce the the job
log. A partial example follows of code you might use:
/* ---------------------------------------------------- */
/* PROCESSING TO BE DONE AFTER THE BACKUP */
/* ---------------------------------------------------- */
IF COND(&FLAG *EQ '*AFTER ') THEN(DO)
/* ADD COMMANDS HERE TO DO WHATEVER YOU WANT TO +
DO AFTER THE BACKUP. */
IF (&RETCODE = 'CPF1E68') THEN(DO)
CHGJOB LOG(4 00 *SECLVL)
ENDDO
----------------------------------------------------------------
LOCATING JOB LOGS:
Your job log output file is printed or placed in an output
queue, depending on how your system is set up. If you are using
the Operational Assistant cleanup function, all of the job logs
are conveniently stored for you in the QEZJOBLOG output queue in
the QUSRSYS library.
If you enter "WRKOUTQ OUTQ(QEZJOBLOG)" on the command line you
can view these job logs.
You will see a similar entry for backup which you can display to
view any errors:
OPT FILE USER USER DATA STS PAGES...
5 QPJOBLOG JANES QEZBACKUP RDY
----------------------------------------------------------------
CHANGING MESSAGES::
If your location does not have personnel who are familiar with
viewing job logs, you might consider changing the message
descriptions shipped with the system so that they are more
helpful for your location. An example follows:
===> CHGMSGD MSGID(CPC1E61) MSGF(QCPFMSG) MSG('BACKUP JOB
SUBMITTED. Press F1 for second level message.') SECLVL('BACKUP
WILL BE RUN AS A BATCH JOB USING JOB DESCRIPTION QEZBACKUP/QGPL.
If you enter "WRKOUTQ OUTQ(QEZJOBLOG)" on the command line you
can view this job log.') SEV(*SAME)
Regards, Chuck
-- Comments provided "as is" with no warranties of any kind whatsoever.
Jack Hefner
I would find the message identifier and look at the message details...I
would bet the default response is set to "C".....
Richard Knechtel <richard....@eds.com> wrote in article
<358693...@eds.com>...
> Ever since I did my Y2K clock change I have had problems with my
> backups. They keep failing.
> The backup requests another tape:
> "Load next tape volume on device TAP01. (C G) "
Richard Knechtel
Charles R. Pence wrote:
>
> An FYI <may be of use>:
>
> APAR= SA62229 SER= EZ PIN=5763SS1OA-079 MS MSGCPF1EE7
> OSP-MSGCPF1EE7 UNEXPECTED ERROR OCCURRED DURING BACKUP WHEN
> BACKUP IS INCOMPLETE AND NOT ALL OBJECTS SAVED
> STAT= CLOSED DOC FESN0900721- CTID= RH2800 ISEV= 2
> SB97/03/04 RC97/03/06 CL97/03/11 PD97/03/12 SEV= 2
>
<snip>
> Regards, Chuck
> -- Comments provided "as is" with no warranties of any kind whatsoever.
Thanks, this is some good information!
Regards,
Richard Knechtel
Thanks to All who sent me information. MY backups are wroking correctly
again. It turned out my QSYSOPR MSGQ was set to *BREAK, I changed it to
*NOTIFY because i figured I needed the messages as *notify so they would
go into the message queue. Turns out that *HOLD did the job. Also Thanks
to Charles for pasoint that APAR information. The change suggested for
the job to default to dumping job logs wrked great. Know I know the
exact file that wasn't getting backed up (a printer device that wasn't
found that is no longer used).
Thanks again!
Richard Daniels
Richard Knechtel wrote:
> Thanks to All who sent me information. MY backups are wroking correctly
Thanks to you, Richard, for having the courtesy to let us know the outcome.
Dick Daniels
WYNTH,Inc