dsnbs chained with the dsnbs freed by tmsclean running
search cancel

dsnbs chained with the dsnbs freed by tmsclean running

book

Article ID: 135469

calendar_today

Updated On:

Products

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

Issue/Introduction

Why the dsnbs have been chained with the dsnbs freed during the TMSCLEAN ?? and how this process can be prevented ? 

TMS REPORT 29 - INVALID POINTERS     OPTIONS: TMC DSNB, NO ENQ                 

ERR75  CHAINING FROM BASE 706285: VOLUME 706285 DSNB 01478224 HAS INCORRECT FILE

ERR75  CHAINING FROM BASE 713959: VOLUME 713959 DSNB 01035383 HAS INCORRECT FILE

ERR33  VOL 706285 HAS NO END TO DSNB CHAIN                                     

ERR33  VOL 713959 HAS NO END TO DSNB CHAIN       



From TMSCLEAN job : 

** WARNING VOLSER=706285 was not scratched => DSNB FILE SEQUENCE NUMBER ERROR 

** WARNING VOLSER=713959 was not scratched => DSNB NOT PART OF VOLUME CHAIN     

Environment

Release :

Component : CA 1 Tape Management

Resolution

If a DSNB chain is being scratched; it does it from the back-to-the-front (so 5 files on a tape, we delete DSNB5, then DSNB4, then DSNB3, then DSNB2 and finally the volume record).

For some abends (AUDIT full for example)  will finish the chain and then abend. 

For a security abend or a cancel however, that does not happen. So,  might have deleted DSNB5 and DSNB4 but then an abend. So now, the volume is chained to DSNB2 and DSNB3 but expects there to be more DSNB’s on the chain AND DSNB3 still points to DSNB4 even though DSNB4 might be on the free-chain (and was most likely already re-used).

 The only way to stop that is to make TMSCLEAN non-cancellable.

 The other thing we have thought about is doing more security testing up-front so that we can detect that UPDATE/ALTER/CREATE authority is not allowed to DSNB3 before doing any updates to the chain.