RE: Some IFS backup conflicts -- MIDRANGE-L

Currently we end WAS and Portal during the backup.  But it's only a 
development machine.

Yes I opened a pmr.  Currently the suggestion is just increase the temp 
storage size.  No clue as to why it's suddenly gotten larger.  Like curing 
the symptom and not the illness.  Jumped on them because of that attitude. 
 Now, they've suggested a PEX trace.  Such fun.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Ingvaldson, Scott" <SIngvaldson@xxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/22/2004 02:35 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: Some IFS backup conflicts






Rob -

I would agree with 2 and 3 and possibly 4.  We've never had a problem with
temporary storage during a backup, but I'm sure we don't have as many IFS
objects as you.  Often the objects that are locked are log files that in
some cases don't even exist when the task is quiesced.  For example, 
FAX/400
locks one object for each receiver job, but it is only an empty file 
waiting
for an incoming fax so it can be omitted pretty safely. 

My theory is that I don't want the operators getting used to seeing
(ignoring?) failure messages nor do I want them calling me every night 
over
something that doesn't need to be saved so I use omits judiciously in the
nightly backup (then pick these objects up with the weekly or monthly
backup) and keep a close eye on the backup joblogs myself.

/QIBM/UserData/OS400/ResourceMonitoringControl is for your HMC, See: 
http://www-912.ibm.com/s_dir/slkbase.NSF/0/657356c75e8a649886256ee700753bda?

OpenDocument

I would definately grill Supportline on the CPC1217 issue, do you end
WAS/WAS Portal while this backup is running?

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group
 

-----Original Message-----
date: Mon, 22 Nov 2004 09:01:34 -0500
from: rob@xxxxxxxxx
subject: Some IFS backup conflicts

During our IFS save there are numerous conflicts.  I have added several 
omits to stop the backup from blowing up.  Seems that after so many 
combinations of CPD384E/CPFA09E (seventeen occurrences) the backup aborts 
with CPC1217-The job exceeded the maximum temporary storage limit.
Possible solutions include:
1 - Do the nightly save in a restricted state.
2 - Quiesce just the conflicting tasks.
3 - Put omits on the conflicting objects and just save those on our every 
8 week save.
4 - Increase job temporary storage.
5 - Break down the IFS save to groups of IFS directories to avoid large 
temporary storage on any one particular step.

Currently we are having the following conflicts.

I am leaning towards a combination of 2 and 3.  Quiesce the tasks if the 
data must be saved more frequently than every 8 weeks.  Omit it if it 
doesn't need the more frequent save.

I've noted the following conflicts prior to the backup just aborting:
/QIBM/UserData/OS400/ResourceMonitoringControl/var/ct/1124614210/* Sixteen 

occurrences of various files instead of the asterisk
/QIBM/UserData/OS400/TCPIP/NTP/QTOT20041121     last object  (last night 
anyway - I quiesced that other task from the previous time ).

Now I am not sure exactly uses the first one.  Perhaps some monitor set up 

in someone's iSeries Navigator?  I thought the 112... was some nightly 
sequence but that is one of the few directories underneath ct, and the 
only numbered one, and it's been there since April.
I assume the second one is for NTP support.  (NTP is the support to sync 
your system clock with a time server.)
Neither, in my book, warrant a nightly backup.  Omit sounds like the 
solution.  As Mellencamp says "What say you?"

Funny thing is that on the Wednesday night backup we have 45 occurrences. 
But the IFS just gave a "CPF3837-225645 objects saved. 45 not saved." And 
went on.
Thursday night we had 72 occurrences and we got the CPC1217-The job 
exceeded the maximum temporary storage limit..
Friday night we had 17 occurrences  and we got the CPC1217-The job 
exceeded the maximum temporary storage limit..
Thursday was the first time we had this CPC1217 situation.  As I am typing 

this I am having another thought.  I was putting on immediate ptf's like 
crazy last week to resolve some issues with WAS / WAS Portal Express. 
Maybe something there is causing this issue.
CPC1217 has a from program of QWTPITPP and a to program of *EXT.  DSPOBJD 
OBJ(QWTPITPP) OBJTYPE(*PGM) DETAIL(*SERVICE) displays no ptf number.
CPD384E and CPFA09E have a from and to program of QSRGENSE.  And the ptf 
displayed on DSPOBJD OBJ(QSRGENSE) OBJTYPE(*SRVPGM) DETAIL(*SERVICE) has 
been applied since August.
Neither of these kick me in the teeth.
http://www-912.ibm.com/ImprovedSearch/searchoptions.jsp
Isn't turning anything up on CPC1217 or MSGCPC1217
So, this is my game plan.  Add an omit for 
/QIBM/UserData/OS400/ResourceMonitoringControl/var/ct/*
/QIBM/UserData/OS400/TCPIP/NTP/*
Open up a pmr on the CPC1217 and go from there.

Rob Berendt
-- 
 
This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contains 
information
intended for the specified individual(s) only. This information is
confidential. If you are not the intended recipient or an agent 
responsible
for delivering it to the intended recipient, you are hereby notified that
you have received this document in error and that any review, 
dissemination,
copying, or the taking of any action based on the contents of this
information is strictly prohibited. If you have received this 
communication
in error, please notify us immediately by e-mail, and delete the original
message.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.