× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Response on the PMR regarding BRMS not telling me that 2 tapes are needed
for recovery:

"In regards to your original question about the recovery report: According
to our developers, BRMS will not go through the media information and list
the volumes that contain the objects that were not saved during the full
backup. If the object was saved after the backup, however, it would be
included in that list. What they suggested was to use the Missed Object
control group process, so whatever objects were missed, BRMS will try to
save them later."

IOW: "working as designed." If I can be a smartaleck: BRMS will not tell
you how to recover the entire system, but will tell you how to recover
everything that was successfully backed up.

I asked another question regarding why it seems it's always one, and only
one, object not saved (in a *LINK backup) but a different object each day:

"In answer to your second questions, why is it only one object (but
different objects) that gets skipped during the backup - it may come down
to what has been started and what is still coming up by the time the IFS
gets saved. Why it's only one file - I don't think there is a reason for
that. If there were locks on multiple objects, it would show it. Again,
it depends on what is up and running by the time it gets to the save. Let
us know what you think."


Anyway, I don't think it's going any farther. Here's the entire PMR
back-and-forth in case any of you have insomnia..


DILGARD FROZEN FOODS INC Update1/30/13 7:07 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby

.
Problem Details
.
Product or Service: Backup and Media Recovery Services for IBM i 7.1.0
Component ID: 5770BR100
.
Operating System: IBM i (i5/OS / OS/400)
.
Problem title
BRMS Recovery Report - tape not listed
.
Problem description
I'm working on trying to save *LINK items save-while-active (SWA) as
much as possible. I'm concerned that when an object is missed because
there was a lock on it, the recovery report is incomplete.

For example, doing a SWA *LINK yesterday, this object,
"/QOpenSys/QIBM/ProdData/acsi/lib/jt400.jar" was not saved because it
was in use.

1) DSPLOGBRM shows that it was not saved.
2) The BRMS report "Recovering The Entire System" (attached) says the
same thing in a nice big ATTENTION paragraph at the beginning. Later
in the same report, where the *LINK recovery information is, it says 1
item was not saved.
3) WRKLNKBRM also shows it was not saved.

However, in the report "Recovery Volume Summary Report" (also attached)
it lists TUE001 (the one used that morning) as the only volume needed
for recovery. That is not correct because an additional volume would
obviously be required. Why does it not list the additional volume from
the prior save of the missed object? If I drill down in WRKLNKBRM, it
shows every unexpired volume that contains the missed object, so BRMS
obviously knows when and where it was properly saved.

.
Business impact ( BusImpact )
Lack of trust in the software. Note that my true question is NOT how
to do a *LINK SWA, but why, when a *LINK object is missed, the Recovery
Volume Summary Report does not list the additional tape needed.

IBM Update1/30/13 7:13 PM

Material received from FTP Server and stored in ECuRep:
Directory: /ecurep/pmr/7/4/74354,500,000/2013-01-30
File: 74354.500.000.QP1A2RCY.pdf 3175 bytes

IBM Update1/30/13 7:13 PM

Material received from FTP Server and stored in ECuRep:
Directory: /ecurep/pmr/7/4/74354,500,000/2013-01-30
File: 74354.500.000.QP1ARCY.pdf 37814 bytes

IBM Update1/30/13 8:00 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130130-205745-systemi_support
File: mail.html 2477 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Hi Jeff,
I understand your concerns about the recovery report. I have a couple
of questions for you.
1. The non-expired tapes that show this particular object being saved -
what kind of save was it? Full, incremental? Any information about
those backups would be helpful.
2. Are you retaining object level detail during the save? And if so,
on the save that backed up the object, you can do a WRKMEDIBRM, find the
*LINK entry, and do a 9 next to it, and drill down through the
directories and find that object, correct? I just want to make sure it
actually is being saved.
3. This may be nothing, but I noticed that you've got a SAVSYS on this
backup, which requires restricted state. Are you bringing the system
out of restricted state before the save of the IFS? Again, it may mean
nothing; it was just something I saw.
.
Thank you,
---------------------------- EMAIL TEXT END ----------------------------

IBM Update1/30/13 8:01 PM

Customer Rep: Jeff

Action Taken: Reviewed recovery report and volume summary. Sent above
email requesting more information regarding the saves that show the
object being backed up.

Action Plan: Delay for response.

DILGARD FROZEN FOODS INC Update1/30/13 8:21 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby

*** Updated by: Jeff Crosby

.
Additional comments
Answers to your questions:

1. Full save. All *LINK saves I do are full saves. I do some
incremental saves on libraries, but that doesn't apply
here.
2. Yes, retaining object level during the save. I can do WRKMEDIBRM,
drill down to that object, and see it there with a size of 0. That,
along with a) displaying it and seeing "Successfully processed . . . .
. : *NO", and the message in DSPLOGBRM, leads me to believe it was
NOT saved.
3. Yes, I am coming out of restricted state before the *LINK save.
This probably won't format well, but here is what the control group
looks like (this is from a post on midrange.com):

10 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*BEFORE)
20 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*ATSTART)
30 *SAVSYS *DFTACT
40 UPSLIB *SYSBAS *DFTACT *YES *NO
50 QMPGDATA *SYSBAS *DFTACT *YES *NO
60 *EXIT BKPRSTNRM
70 *IBM *DFTACT *YES *LIB BACKUPS
*NONE
80 *ALLUSR *SYSBAS *DFTACT *YES *LIB BACKUPS
*NONE
90 *ALLDLO *DFTACT *YES *YES
100 *EXIT ENDSBS SBS(QHTTPSVR) DELAY(60) ENDSBSOPT(*NOJOBLOG)
110 *LINK *ALLAVL *DFTACT *YES *YES BACKUPS
*NONE
120 *EXIT STRSBS SBSD(QHTTPSVR/QHTTPSVR)
130 *EXIT STRTCPSVR SERVER(*HTTP) HTTPSVR(*ALL)
140 ALLSPLF *SPL *DFTACT
150 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*ATEND)
160 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*AFTER)

Stuff for you to know:

1) It is BRMS *CONSOLE processing, so the system automatically enters
restricted state.

2) The *EXIT points at seq 10, 20, 150, and 160 is a CL program
BKPBRMEXT I wrote that does housekeeping such as sending messages
and/or emails, stop/start order processing, journal maintenance,
hold/release the journal maintenance job scheduler job, UPS monitoring,
etc.

3) The *EXIT point at seq 60 is a CL program BKPRSTNRM I wrote that
starts the controlling subsystem. My startup CL program puts an entry
on a data queue when finished. This *EXIT waits up to 10 minutes on
that data queue entry. If not received within 10 minutes, it moves on
(it actually takes only about 1 minute). After this step, the entire
system is back active except the journal receiver maintenance job
scheduler job is not yet released. (That happens at the very end.)

4) The *EXIT points at seq 100, 120, and 130 are to stop/start the
QHTTPSVR subsystem so that the *LINK at seq 110 will save everything
without issue.

5) The omit list in BRMS ("QLNKOMT") omits the following in the *LINK
save at seq 110:
/Bytware/StandGuard/AV/logs
/FAXD01/RCVFAX
/easy400apc/logs
/QIBM/UserData/OS400/MGTC/service


Timings:

From the start of the backup to the message "Subsystem QCTL started"
(meaning restricted state is being lifted) is 14 minutes. It takes a
few minutes for everything else to get going, but restricted state has
been reduced to no more than 20 minutes.

For seq 100 through 130. The time from "Subsystem QHTTPSVR ending in
progress." to "Subsystem QHTTPSVR started." is 20 minutes. The *LINK
save takes a while!

The grand total time for the backup was 87 minutes, of which ~20
minutes was restricted state. Before, when the entire backup was in
restricted state, the grand total time was 74 minutes.

I will trade the extra 13 or so minutes for the entire process in
exchange for getting down to 20 minutes in restricted state.

This backup will run at 3am when, normally, no one will be on the
system save maybe the night crew manager. So I don't know exactly how
well it would work in the middle of the day when everyone is banging
away on the keyboard.


.

IBM Update1/30/13 8:47 PM

Action Taken: Deleted the secondary and notified the primary.

IBM Update1/30/13 9:16 PM

Customer Rep: Jeff

Action Taken: Responded with the above email.

Action Plan: Delay for response.

IBM Update1/30/13 9:21 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130130-221556-systemi_support
File: mail.html 2554 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Hi Jeff,
Thank you for the data. Like I said, it may not help us determine
what's going on, but it's good to know.
When I asked about whether or not you could see the entry in the
WRKMEDIBRM, I was referring to the times that the object was saved, and
not this last attempt. I want to verify that BRMS knows that object was
in fact saved at some point in time. Also, can you do a DSPPTF 5770BR1
and let me know the first PTF number on there, that would be helpful.
We also might need the job log from this last attempt, where the object
was not saved, along with the flightrec from that time period. If it's
available, you can send the job log as a spool file. We could also use
the flightrec file. Would you run the following command and send us the
resulting spool file?
CPY OBJ('/tmp/brms/flightrec') TOOBJ('/tmp/brms/flightrec.txt')
TOCCSID(*PCASCII) DTAFMT(*TEXT)
-Kate Bender
IBM iGSC
---------------------------- EMAIL TEXT END ----------------------------

DILGARD FROZEN FOODS INC Update1/30/13 9:44 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby
*** Updated by: Jeff Crosby

.
Additional comments
Yes, via WRKMEDIBRM I can see that it was saved on another tape.

DSPPTF 5770BR1:
SI47935 Temporarily applied
SI47215 Temporarily applied
SI47039 Permanently applied
SI46340 Permanently applied
SI45327 Permanently applied
SI44710 Permanently applied
SI43868 Superseded
SI42925 Permanently applied
SI42449 Permanently applied
SI42066 Permanently applied
SI41206 Superseded
SI40005 Superseded
SI38740 Superseded
SI37987 Permanently applied
SI37264 Superseded
SI35676 Superseded

The joblog and BRMS flight recorder files are attached as .zip file
because they are huge.

The BRMS control group in question started at 3:01am on 1/29/2013.

.

IBM Update1/30/13 9:51 PM

integrity test on file 2013-01-30/74354.500.000.flightrec.zip : ok

IBM Update1/30/13 9:51 PM

Material received from FTP Server and stored in ECuRep:
Directory: /ecurep/pmr/7/4/74354,500,000/2013-01-30
File: 74354.500.000.flightrec.zip 16304760 bytes

IBM Update1/30/13 9:51 PM

Material received from FTP Server and stored in ECuRep:
Directory: /ecurep/pmr/7/4/74354,500,000/2013-01-30
File: 74354.500.000.QPJOBLOG855610.zip 919201 bytes

IBM Update1/30/13 9:53 PM

integrity test on file 2013-01-30/74354.500.000.QPJOBLOG855610.zip : ok

IBM Update1/30/13 9:57 PM

Auto-requeued to the location of primary call, on SRWK4,163.

IBM Update1/30/13 10:44 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130130-234041-systemi_support
File: mail.html 2284 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Hi Jeff,
I looked over the data and the flightrec file. I also discussed this
issue with a Subject Matter Expert. Would you be willing to send us a
screen shot of that object showing up on an active volume? Also, I'd
like to check something - are you duplicating the media after the save?
I'm just trying to rule out reasons why it would not show up. For
example, that object is saved on volume ABC123. That volume is dupped
to another volume, DEF456. ABC123 is manually expired, but DEF456 still
exisits as a volume with the object on it. When you run the report, it
ignores the duplicate volumes, so it wouldn't look at DEF456. Let me
know if that makes sense.
Thank you,
-Kate
---------------------------- EMAIL TEXT END ----------------------------

IBM Update1/30/13 10:53 PM

Customer Rep: Jeff

Action Taken: Reviewed data and sent customer above email.

Action Plan: Delay for response.

DILGARD FROZEN FOODS INC Update1/31/13 12:34 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby
*** Telephone: (260) 467-4217
*** Alt. telephone: (260) 422-7531
*** Mobile phone: (260) 750-6052
*** Email: jlcrosby@xxxxxxxxxxxxxxxx

*** Updated by: Jeff Crosby
*** Email: jlcrosby@xxxxxxxxxxxxxxxx

.
Additional comments
Attached is a 13-page PDF of 13 screenshots. (BRMSRequestedScreenShots.
pdf)

We use 5 tapes/week for this back and alternate weeks 1 and 2. The
tapes are named MON001, TUE001, WED001, THU001, FRI001, MON002, TUE002,
WED002, THU002, and FRI002

The first 10 screenshots in the attached PDF show that this item was
saved every day the past 2 weeks except on Tuesday, 1/29.

We dup the Friday tapes to JLC001 and FAY001 every week which are
stored at 2 different offsite locations. We also dup the first Friday
of every month to a monthly tape (JAN001, FEB001, etc) that is stored
offsite and kept for a year.

The last 3 screenshots in that attached PDF show that this file was
saved successfully on every tape except the day in question. Including
the 2 days since Tuesday, 1/29.

Some additional information. Each day this *LINK backup seems to miss
one and only one item. Tuesday, 1/29, it was the file in question.

Wednesday, 1/30, it was
/QIBM/ProdData/OS/OSGi/LWI71/runtime/isc/eclipse/plugins/com.ibm.
isclite_7.1.1.6.jar. (When I looked for this file yesterday during the
day, it no longer exists on the system, another mystery.)

Today, 1/31. the missed file is
/QIBM/ProdData/OS400/iSeriesNavigator/EXPANDED/COM.IBM.I5OS.WEBNAV.
SYSTEMINAVIGATOR/WEB-INF/lib/jt400.jar. If I drill down, I find it was
saved successfully every time except today (Attached PDF
BRMSRequestedScreenshots2.pdf).

An aside: The BRMS flight recorder is huge, like 300mb or more. Does
this wrap? Or will it continue to grow?
.

IBM Update1/31/13 12:37 PM

Material received from FTP Server and stored in ECuRep:
Directory: /ecurep/pmr/7/4/74354,500,000/2013-01-31
File: 74354.500.000.BRMSRequestedScreenShots2.pdf 10782 bytes

IBM Update1/31/13 12:37 PM

Material received from FTP Server and stored in ECuRep:
Directory: /ecurep/pmr/7/4/74354,500,000/2013-01-31
File: 74354.500.000.BRMSRequestedScreenShots.pdf 36239 bytes

IBM Update1/31/13 12:38 PM

Auto-requeued to the location of primary call, on SRWK4,163.

IBM Update2/1/13 4:41 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130201-173654-systemi_support
File: mail.html 1870 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Hi Jeff,
I see that the object was saved on volume MON001 on 1/28th. Just to
verify - you do not duplicate that tape, correct? We were not able to
recreate the issue here, so we will now go to the developers and see
what we can find. I will keep you posted.
-Kate Bender
IBM iGSC
---------------------------- EMAIL TEXT END ----------------------------

IBM Update2/1/13 4:49 PM

Customer Rep: Jeff

Action Taken: Created CPS discussion 94HMJ4.

Action Plan: Delay for response from developer.
=============== KMM Information ================
Date: 13/02/01
Time: 1649
Description: CPS Discussion Item
Action: Created
Contributed: Yes
Content Source: CPS
Content: 94HMJ4
================================================

IBM Update2/1/13 5:45 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130201-184505-systemi_support
File: mail.html 3309 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Jeff,
We have a couple of questions for you. How does the recovery report
run? It appears that it's part of the backup job that runs, and not
part of maintenance. Also, if you were to run the recovery report
command right now, does it match up with the report from this morning?
We just want to rule out any timing issues.
In answer to your question about the size of the flightrec file; there
is a pre-determined size. When it reaches that size, BRMS deletes the
flightrec.bku file, renames the flightrec to flightrec.bku, and creates
a new flightrec file. The size of the flightrec file can be changed in
the following way:
To change the flight recorder size (in megabytes) to 001-999 run this
command:
CALL PGM(QBRM/Q1AOLD) PARM('FRSIZE' '*SET' ' XXX')
- Where XXX is equal to 001 - 999. Note: 0's must be added to the front
of the numbers
.
To show the current flight recorder size run this command:
CALL PGM(QBRM/Q1AOLD) PARM('FRSIZE' '*DISPLAY')
Thank you,
-Kate Bender
IBM iGSC
---------------------------- EMAIL TEXT END ----------------------------

IBM Update2/1/13 5:45 PM

Customer Rep: Jeff

Action Taken: Sent above email requesting more data on how the reports
get generated.

Action Plan: Delay for response.

DILGARD FROZEN FOODS INC Update2/1/13 6:15 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby
*** Updated by: Jeff Crosby

.
Additional comments
Correct, MON001 was not dupped. The tapes that regularly get dupped
are Friday's (FRI001 and FRI002).

Recovery report: It gets run as part of the last *EXIT in the control
group. (It is not actually printed, though. The spool output gets
converted to PDF in the IFS, then gets copied from the IFS to another
server, and also gets emailed as an attachments to 2 different emails
addresses I have. Unless Armageddon arrives, I should be able to get a
recovery report somewhere. <g>)

As far as the recovery report being the same now as when it was run
this morning: If I were to do so, I don't know that it would help you
for 2 reasons: 1) This morning's backup has been dupped to 3
additional tapes being stored offsite, and 2) I ran a different control
group today that stays in restricted state throughout the entire
process.

I'm running a different control group on Fridays because 1) Friday's
tapes are the ones dupped, and 2) I tell it OMITS(*IGNORE) so nothing
gets skipped. The only way I trust that to happen now is to stay in
restricted state throughout.

Thanks for the info on the flight recorder size. I have the disk space
so I'm going to leave it as is for now. I just didn't want it to grow
uncontrolled.
.

IBM Update2/1/13 9:49 PM

UPDATE: Discuss with Jeff.

IBM Update2/1/13 10:48 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130201-234836-systemi_support
File: mail.html 1964 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Jeff,
I'm still discussing this with our developers, but from what they have
told me, it's possible this is working as designed; BRMS is not
programmed to pick up the missing objects from each backup. I
understand your concern about this, and I'm working with the developers
to come up with a process for you. I will keep you informed.
Thank you,
-Kate Bender
IBM iGSC
---------------------------- EMAIL TEXT END ----------------------------

IBM Update2/1/13 10:49 PM

Customer Rep: Jeff

Action Taken: This may be working as designed, as BRMS is not
programmed to pick up missing objects; it would take too much effort to
do so. Discussing with developers for options.

Action Plan: Continue discussion with developers.

DILGARD FROZEN FOODS INC Update2/4/13 2:29 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby
*** Updated by: Jeff Crosby

.
Additional comments
Another day, another *different* file missed due to being in use.

Today (Mon 2/4) it was:
QIBM/ProdData/OS/OSGi/LWI71/runtime/uistandard/eclipse/plugins/com.ibm.
rcp.channelframework_6.1.2.200803311542/channelfwservice.jar.

I now have another aspect/question to this service request. In
addition to the question why doesn't BRMS list the other tape I need
for a full recovery, I also want to know why there is seemingly one,
and only one, file that gets skipped each day for being in use; and
it's always a different file?

.

IBM Update2/4/13 3:43 PM

ACTION TAKEN: NC Recommended. Deleted secondary. Reviewed PMR update.
Discussed with PMR owner.

ACTION PLAN: RQ to owner's work queue for follow-up

IBM Update2/5/13 3:46 PM

Customer Rep: Jeff

Action Taken: Sent the above email to customer in response to his
questions.

Action Plan: Delay for response.

IBM Update2/5/13 3:46 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130205-164543-systemi_support
File: mail.html 2558 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Jeff,
In regards to your original question about the recovery report:
According to our developers, BRMS will not go through the media
information and list the volumes that contain the objects that were not
saved during the full backup. If the object was saved after the backup,
however, it would be included in that list. What they suggested was to
use the Missed Object control group process, so whatever objects were
missed, BRMS will try to save them later.
In answer to your second questions, why is it only one object (but
different objects) that gets skipped during the backup - it may come
down to what has been started and what is still coming up by the
time the IFS gets saved. Why it's only one file - I don't think there
is a reason for that. If there were locks on multiple objects, it would
show it. Again, it depends on what is up and running by the time it
gets to the save.
Let us know what you think.
Thank you,
-Kate Bender
IBM iGSC
---------------------------- EMAIL TEXT END ----------------------------

DILGARD FROZEN FOODS INC Update2/5/13 8:09 PM

*** Electronic submission by customer via SR tool, version 2.5
*** Preferred contact method: Email-address.
*** Customer contact full name: Jeff Crosby
*** Updated by: Jeff Crosby

.
Additional comments
Regarding your statement "According to our developers, BRMS will not go
through the media information and list the volumes that contain the
objects that were not saved during the full backup. If the object was
saved after the backup, however, it would be included in that list.
What they suggested was to use the Missed Object control group process,
so whatever objects were missed, BRMS will try to save them later."

In other words, "working as designed".

Suppose I run the control group I've been running and everything gets
saved EXCEPT a single *LINK item. The subsequent recovery report shows
only 1 tape needed and 1 object not saved. (This is what has been
happening.)

Here's a hypothetical. Now suppose I took advantage of the Missed
Object control group, which recorded that 1 object not saved.

Scenario 1:

I now run that Missed Object control group and it successfully saves,
appending onto the SAME tape. What will the recovery report show now?
Will it show everything successfully saved onto that single tape? Or
will it show only that single item available for recovery with
everything else missed? I assume the former.

Scenario 2:

I now run that Missed Object control group and it successfully saves
onto a completely different tape. What will the recovery report show
now? Will it show only that single item available for recovery with
everything else missed? Or will it fall back to another tape for
everything else and list both tapes on the recovery report? If the
latter, how can it do this in this case when not in the reverse?

Scenario 3:

I now run that Missed Object control group and it successfully saves,
OVERWRITING the SAME tape. What will the recovery report show now?
Will it show only that single item available for recovery with
everything else missed? Or will it fall back to another tape for
everything else and list both tapes on the recovery report? If the
latter, how can it do this in this case when not in the reverse?

I'm not trying to be a smart you-know-what. I'm losing confidence in
the BRMS recovery report being complete.
.

IBM Update2/5/13 9:45 PM

Customer Rep: Jeff

Action Taken: Passed the above information to the developers.

Action Plan: Delay for response.

IBM Update2/7/13 6:43 PM

Customer Rep: Jeff

Action Taken: Sent above email to customer.

Action Plan: Delay for response.

IBM Update2/7/13 6:43 PM

ECuRep Mail Gateway - Received Mail and stored in ECuRep
------------------------------------------------------------------------
Mail From: systemi_support@xxxxxxxxxxxxxx
/ecurep/pmr/7/4/74354,500,000/mail20130207-193956-systemi_support
File: mail.html 2572 bytes
---------------------------- EMAIL TEXT START --------------------------
This email was also sent to: jlcrosby@xxxxxxxxxxxxxxxx
Hi Jeff,
.
I sent your scenarios to the developers, and here is their response:
.
Scenario #1 - The IFS list (with the missed ifs objects) should be
next after the *LINK full.
Scenario #2 - Depends on what his selections are on the STRRCYBRM....if
the volume is in a different location it would be omitted...I'm guessing
it would work fine...but depends on customer's setup.
Scenario #3 - BRMS will not overwrite the data unless you expire the
volume...but if you did...then yes for a *SYSTEM recovery report we
would try to find libraries, etc that are needed however far back we
need to go.
.
Ultimately, if you do a full save, BRMS includes that, whether or not
all of the objects were saved. If you run an incremental save of the
missing objects after the full, it would be included on the report.
.
I know it's not the answer you're looking for. Let us know if you have
any further questions.
.
Thank you,
.
-Kate Bender
IBM iGSC
---------------------------- EMAIL TEXT END ----------------------------











On Thu, Jan 31, 2013 at 9:50 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

Another day, another unsaved file. :) This time it was:

*
/QIBM/ProdData/OS400/iSeriesNavigator/EXPANDED/COM.IBM.I5OS.WEBNAV.SYSTEMINAVIGATOR/WEB-INF/lib/jt400.jar
*
*
*
*I opened a PMR yesterday and IBM is definitely pursuing my concern that
BRMS wasn't telling me I needed 2 tapes for restore. So far, they have
asked for the BRMS recovery reports, console joblog, BRMS log, BRMS flight
recorder, and screenshots showing the original file in question was indeed
saved on multiple other tapes.*
*
*
*I'll post the resolution.*
*
*


On Wed, Jan 30, 2013 at 8:26 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

Today, a different single file was not saved. It was:


/QIBM/ProdData/OS/OSGi/LWI71/runtime/isc/eclipse/plugins/com.ibm.isclite_7.1.1.6.jar

The jt400.jar file that was NOT saved yesterday WAS saved today. I made
no changes.

And the BRMS recovery report run this morning says I need both
yesterday's and today's tape for recovery. I thought "good news!" in that
it would tell me I needed yesterday's tape to recover the file mentioned
above. But it was not to be. The reason BRMS says I need yesterday's tape
is because I deleted an old test library yesterday. I need yesterday's
tape to restore that now deleted library. No reference to needing it for
*LINK restore.

Evidently BRMS doesn't keep data to the same level of granularity on
*LINK. I may just open a PMR later and see what the IBM BRMS people have
to say on this.



On Tue, Jan 29, 2013 at 12:32 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

Dan & Jim,

I understand what you are saying with regard to not worrying about
saving this file, jt400.jar, but I'm just not comfortable with it. I don't
want to start a list of files that I have to go find somewhere when a
recovery is necessary. Not even one.

In addition, the recovery report generated by BRMS after this morning's
backup states the only tape I need for recovery is the tape I used this
morning. Even though jt400.jar was not saved. The recovery report should
also tell me that I need the tape used yesterday morning when jt400.jar WAS
saved. Why doesn't it tell me that? I simply don't understand why. What
else isn't BRMS telling me? I looked at the WRKLNKBRM command and drilled
down to the jt400.jar file in question. It is listed on the tape used this
morning as size 0 bytes, and says it was NOT saved. It does show under
yesterday's tape as being saved. Again, why doesn't BRMS tell me I need
yesterday's tape? This situation, all by itself, really makes me nervous.

People keep telling me not to worry about this file or that file or that
directory. Performance data and log files I understand. I just can't make
myself go further with it.

My goal was to do a complete 100% save of the system 5 mornings a week,
with as little downtime as possible. I'm slowly coming to the conclusion
it cannot be done, unless I do the entire backup completely restricted.
That's what I'm doing now without all this study and testing. I'm not
sure where I'm heading now. Do this "new" BRMS control group Mon-Thu and
do the old, completely restricted, BRMS control group on Fridays? I just
don't know.






On Tue, Jan 29, 2013 at 10:18 AM, Jack Kingsley <
iseriesflorida@xxxxxxxxx> wrote:

Jeff, did a little more on this, looks like this ifs
directory(/QOpenSys/QIBM/ProdData/acsi) is default for a product called
IBM
Tivoli Directory Integrator.


http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2Fcom.ibm.IBMDI.doc_6.1.1%2Fpdguide17.htm



On Tue, Jan 29, 2013 at 10:07 AM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

I agree with Dan. Exclude it from your save since it is easily
recovered in other ways, and does not change very often. Your
monthly/Quarterly full system saves should be plenty. (or after a
group/cumulative installation)

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 1/29/2013 9:01 AM, Dan Kimmel wrote:
Don't worry about backing it up every day. It changes only via PTF.
It
is easily recovered if necessary.

jt400.jar is the Toolkit for Java. It contains the JDBC database
drivers
for Java as well as a whole bunch of java classes for accessing IBMi
API's.
It might have been in use from iNav or one of the HTTPSVR instances.

-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby
Sent: Tuesday, January 29, 2013 8:50 AM
To: Midrange Systems Technical Discussion
Subject: jt400.jar in use

All,

I've spent a couple of weeks re-engineering our nightly BRMS backup
to
be as much save-while-active (SWA) as possible (the subject of a
rather
long thread here).

I put it in production today and it ran flawlessly except for one
little
hiccup. This *LINK object,
/QOpenSys/QIBM/ProdData/acsi/lib/jt400.jar, was
not saved because it was in use. This was at 4:19am with no users
signed
on. Controlling subsystem would have been started about 1 hour
earlier,
and subsystem QHTTPSVR would have been ended when the error occurred.

When I drilled down in Navigator, it did indicate the file had been
used
today, but does not give a time. There is no WRKOBJLCK equivalent
for IFS
files, but I found this online CALL QP0FPTOS PARM(*LSTOBJREF
'/ifspath/ifsfile' *FORMAT2) that showed me there were no locks on it
now.
<g>

I had tested the *LINK save as SWA close to a dozen times over the
past
10 days and this particular file never showed up as being in use. My
question is, essentially, why today? Was this a fluke? How can I
find out
what was using this file at that time?

I did download and stage the latest Java group PTF yesterday
afternoon,
to be applied the next IPL, if that makes a difference.

I just don't want this file getting missed every day.


--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion
of my
company. Unless I say so.
--
--
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.


--
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.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.





As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.