Re: More tape required for backup -- MIDRANGE-L

Did a PRTERRLOG *VOLSTAT. Had some collectively named tape show a
large number of temporary write errors. Showed that to boss. He is
reluctant to change things, as this system is scheduled to go away in
ten months. He is also not thrilled with untraining operators who are
just used to doing things. But, we have another meeting scheduled.
The large temporary write errors could be a single tape or several.
He said these are about ten years old.

Tapes are oddball. All 3590. But at least two different capacities.

Progress by inches. Or, from StarTrek IV: The Voyage Home: Kirk to
Scott: Congratulations, you have closed the barn door after the cows
have left.

John McKee

On Wed, Jan 25, 2012 at 3:15 PM, <rob@xxxxxxxxx> wrote:

A successful 1/4" cartridge tape backup on a Basic 4 was cause for a beer.

IBM's early AS/400 reel-to-reel backups used to have a bar graph on the
device itself that give an estimate on how much tape was used as it went
along. I REALLY miss that. Well, not so much with tape libraries now.
But back when I had to physically mount tapes when each was full...

Better get more tapes ordered up.

Take the clear option on PRTERRLOG to reset your statistics. And TRY to
use separate volume ids. Then you can see how much is written to each.
Although, even with the same backup you will see wide discrepancies. Most
of that is because it displays how much data it was BEFORE compressing out
to tape. DB2 compresses different than other areas of the IFS.
Volume ---Temporary Errors--- --------M Bytes--------
ID Read Write Read Written
0 0 1 1
BR0095 0 0 1 506933
BR0104 0 0 1 450784
BR0106 0 0 1 483953
BR0181 0 0 1 2448038

181 was the first tape of the full system save. It compressed the hell
out of DB2.

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: John McKee <jmmckee@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 01/25/2012 03:34 PM
Subject: Re: More tape required for backup
Sent by: midrange-l-bounces@xxxxxxxxxxxx

I was wondering about the capacity of a 3590 tape, and if it was
likely that we just managed to finally get large enough to need that
third tape. We >may< have been lower on usage - again, I don't look
at that often. Good to stay out of sa's turf - whether he looks or
not. I don't know if the SAVE 21 does data compression, or just how
much a 3590 can hold. I suspect things have improved DRAMATICALLY
since my days with the B50. We had a 2410 (might be wrong on the
drive number - been too long to mater) tape drive and 8G of DASD. I
got a few calls about the backup wiping out due to a tape error. It
was worse than pulling teeth to get new tapes and have older ones
(unknown age) tested for errors. Probably would have been done a
whole lot faster if the person who authorized purchase of tape got the
wake-up calls in the wee hours of Sunday morning. Eight+ hours for
backup.

John McKee

On Wed, Jan 25, 2012 at 1:59 PM, <rob@xxxxxxxxx> wrote:

Yes, GO SAVE 21 does it outside of BRMS. Although QSYSOPR or DSPLOG

will

have a few messages that indicates that, since BRMS is installed, it's
chomping at the bit to be of assistance. We had it installed some years
before actually using it.

Not using unique id's is a real cluster ... for the two reasons you
mentioned: screws up PRTERRLOG and baffles BRMS.

I supposed you could see if you have old joblogs from saves and count
blocks - yee haw!

But I concur with Chuck, probably some clean up is being missed. We IPL
and do full system saves once a quarter. I have documented clean up

steps

on what I clean up during the week prior.

Then again maybe when the SA's away, the mice will play. People going
nuts creating test data and stuff?

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: John McKee <jmmckee@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 01/25/2012 02:12 PM
Subject: Re: More tape required for backup
Sent by: midrange-l-bounces@xxxxxxxxxxxx

We use GO SAVE 21. But, I took a look anyway. No BRM log.

John McKee

On Wed, Jan 25, 2012 at 12:40 PM, Jack Kingsley
<iseriesflorida@xxxxxxxxx> wrote:

Maybe try the DSPLOGBRM command, how GO BRMS, then take reports option,
there are many reports to pick from, maybe one of those might help you

out.

On Wed, Jan 25, 2012 at 12:21 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 25-Jan-2012 08:50 , John McKee wrote:

Our sa is away. The last two weeks, the full backup (GO SAVE 21)

has

required three tapes, where it normally requires two. <<SNIP>>
do not believe usage has changed much. I am wondering if we just
stepped over the threshold that two tapes can hold. <<SNIP>>

Might be that some "manual cleanup" [periodic or while in restricted
state after the save] was being done by SA, but the now unchecked

growth

has pushed the limit. That is to suggest, that sometimes those

actions

do not make their way into the documented procedural steps that

somebody

else might have to perform as a backup\replacement.

For example: History logs and audit journal receivers sometimes
either are not saved :-( and\or saved separately and then deleted.
Perhaps deleting all previously saved\eligible receivers, post-save.
The QRPLOBJ which maybe was getting cleared; AFaIK that library is

part

of the save-21. There may also be "log files" in some directories

that

were being purged, with or without prior save. And if spool data is
part of the saves, perhaps some SPLF cleanup using or outside of the

GO

CLEANUP.

Regards, Chuck
--
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.

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

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