TMSAUDIT file records released during the TMSCOPY
Article ID: 138379
Updated On:
Products
Issue/Introduction
TMC and AUDIT files are shared between several partitions.
TMSCOPY1 and TMSCOPY2 ended with rc=8 and released only few audit records.
TMSBINQ of TMSCOPY1:
LPAR=AAAA REC=00623088 LPAR=BBBB REC=00631824 LPAR=TTTT REC=00630168
LPAR=GGGG REC=00414408 LPAR=DDDD REC=00419664 LPAR=SSSS REC=00319128
LPAR=CCCC REC=00532992 LPAR=VVVV REC=00418608
LPAR=EEEE REC=00423144
LPAR=FFFF REC=00318576
The audit records can only be released up to the minimum number (318576). And the next available audit record was over 600000. So the AUDIT file was quite full after the tmscopy.
26 minutes later:
LPAR=AAAA REC=00634368 LPAR=BBBB REC=00634104 LPAR=TTTT REC=00634392
LPAR=GGGG REC=00414408 LPAR=DDDD REC=00419664 LPAR=SSSS REC=00319128
LPAR=DDDD REC=00634320 LPAR=AAAA REC=00418608
LPAR=D002 REC=00634200
LPAR=S002 REC=00634344
So the minimum was 319128 not much more than above.
It took two hours to get (rc=0):
and the audit file was nearly empty.
Environment
Release : 14.0
Component : CA 1 Tape Management
Resolution
If there is an LPAR that is NOT dormant (there is some activity every 30 minutes) but only creates a few records every couple of hours, this is going to be a problem. We only “release” an LPAR if it has been in-active for 30 minutes. But, if it is only writing 1 or 2 audit records every 30 minutes it can take many hours before it fills up its BLOCK. And so that BLOCK remains the “low water mark” for many hours.
What it could do is simply run TMSINIT on all slow LPAR’s prior to running the TMSCOPY. That will “force” all LPAR’s to catch up and fill their current AUDIT block.
Feedback
