|
midrange.com
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Evan,
STRSST
1. Start a service tool
1. Product activity log
4. Work with removable media lifetime statistics
Volume ---Temporary Errors--- --------K Bytes-------
ID Read Write Read Written
GDIONE 0 3 2 2
0 12 1367 1367
IBMRD 0 419 2 1468936
TAP001 0 152 1165986 696980
GDS 0 119 1902413 183744
EDI#1 0 7 2 126533
IBMIRD 0 40372 2928606081 2543814963
DOMMON 0 886 2946200 3095437656
******** 0 0 2 2
ADFRI 0 0 216 454533420
ADMON 0 0 211063711 3769565761
ADSUN 0 0 5482 2912480679
ADTHU 0 0 211127799 3891118479
ADTUE 0 0 3929 3867142579
ADWED 0 0 4302 324298563
DAILY 0 0 2 2
DMWSAT 0 0 135818493 3211327657
DOMTHU 0 0 135268551 2993751130
DOMTUE 0 0 4829615 3065151502
DOMWED 0 0 3749039 3074274906
FRI 0 0 10255055 432084840
GDI 0 0 3639583 7
GDIHMI 0 0 1753342 25
GDISYS 0 0 1 1
IMBIRD 0 0 3 3
IOWA 0 0 191755 1
MARK 0 0 111496 5
MON 0 0 19023762 887590468
MSDTAP 0 0 135521 2
SAT 0 0 3878532 4258458436
SUN 0 0 112742 103202955
TAP006 0 0 2164 374421400
THU 0 0 10013122 3307779355
TSM01 0 0 27941392 34
TSM02 0 0 173 16
TSM03 0 0 66 3
TSM04 0 0 66 3
TSM05 0 0 66 3
TSM06 0 0 132 6
TSM07 0 0 132 6
TSM08 0 0 68 5
TSM09 0 0 66 3
TSM10 0 0 66 3
TUE 0 0 12396795 729753780
VOL01 0 0 49392 7
VOL02 0 0 54392 2
WED 0 0 2921441 536815271
WEEKLY 0 0 7 7
010499 0 0 10705 4
122995 0 0 8363 1
122997 0 0 6972 1
123096 0 0 13765 3
The volume id involved is DOMTHU. However, I know that the nightly backup
only initializes the first tape and the others are previously initialized
and rely on expiration dates. I wonder if it might be IBMIRD?
By the way, is there a way to batch print this out? I wouldn't mind
printing that out as part of the backup procedure.
I am going to use F10 and start fresh.
But this:
STRSST
1. Start a service tool
1. Product activity log
5. Display or print removable media session statistics
From:
Date . . . . . . . . 12/05/02
Time . . . . . . . . 19:59:00
To:
Date . . . . . . . . 12/05/02
Time . . . . . . . . 23:59:59
Results in: No session entries found
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
Evan Harris <spanner@ihug.co.nz>
Sent by: midrange-l-admin@midrange.com
12/12/2002 12:25 PM
Please respond to midrange-l
To: midrange-l@midrange.com
cc:
Fax to:
Subject: RE: Backup performance issue.
Rob
I think you said that you had checked SST for tape errors and had found
none. Nevertheless these figures smack of tape retry errors if you can't
find anything else in the job log, the history log or the operator message
queue.
You've probably considered this, but is it possible that tapes are cycled
in such a way that the same tapes are re-used on the same days (and these
same days are the days you notice problems) ? This might go some way to
explaining your errors.
I used to check the SST tape log on a weekly basis looking for any bad
tapes, but the report never indicated any that it thought were going bad -
not even tapes that caused a backup to fail due to a media error.
Regards
Evan Harris
>This is a multipart message in MIME format.
>--
>[ Picked text/plain from multipart/alternative ]
> Start of 2nd 3rd 4th End of
>SAV
>Date Submitted INZTAP SAV* Vol Vol Vol or
abort
> Aborted?
>12/9/2002 Monday 20:00 20:00 20:01 21:00 21:55 22:47 23:09
> N
>12/5/2002 Thursday 20:00 20:00 20:01 20:59 22:45 23:36 23:45
> Y
>
>As you can see the time from the start of the second volume until the
>start of the third volume seemed to be rather large on the night the
>backup had to be aborted. There were no messages in the joblog. There
>was nothing indicated in the output created by the SAV command. Yes,
>there were numerous other jobs running, (but NO Domino jobs). Also
>included in these jobs were other saves. Yes, at the same time that we
do
>the save to this 3590 we run:
>a job to save to one 3581
>a job to save to another 3581
>a job to save some libraries to a save file.
>But, heck, these jobs run every night and don't seem to have any effect.
>And the performance data didn't seem to indicate any spikes.
>
>Rob Berendt
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
