TMSAUDIT file records released during the TMSCOPY
search cancel

TMSAUDIT file records released during the TMSCOPY

book

Article ID: 138379

calendar_today

Updated On:

Products

CA 1 Flexible Storage CA 1 Tape Management - Copycat Utility CA 1 Tape Management - Add-On Options

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.