dsnbs chained with the dsnbs freed by tmsclean running
Article ID: 135469
Updated On:
Products
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.
Feedback
