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

What that means is you need some new tapes, not new procedures.... Just buy what you need for the next several months. Besides, if customers experience is any measure, with 10 year old tapes the chances of a clean recovery from those tapes are almost as good as a snowball's chance in the Caribbean. Not big.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 1/26/2012 2:53 PM, John McKee wrote:

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