Db2 z/OS Utilities: Identify and avoid some MERGECOPY or MODIFY Recovery anomalies
Just a little note this month about a strange anomaly in the way MERGECOPY and MODIFY RECOVERY seem to work. Let’s begin with MERGECOPY.
1 – MERGECOPY to the death
How many IICs to change a lightbulb?
I was doing some tests, to see how many Incremental Image Copies you can take before RECOVER dies, about 71 by the way, and found this out…
SCRATCHing my head
I did a Full Image Copy, then various updates, and three Incremental Image Copies. Due to bad luck, my Full Image Copy was “accidentally” scratched… Whoops!
MERGECOPY runs
I ran the MERGECOPY and look what happened:
DSNU000I 199 10:37:11.20 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DC10MC00MCU012
DSNU1044I 199 10:37:11.21 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
DSNU050I 199 10:37:11.23 DSNUGUTC - MERGECOPY TABLESPACE R510D0DC.R510S81 NEWCOPY YES
DSNU463I 199 10:37:11.30 DSNUYBR3 - THE PRIMARY IMAGE COPY DATA SET SETEMP.R510D0DC.R510S81.P0000.D17195.T1734 WITH
DATE=170714 AND TIME=174140
IS PARTICIPATING IN MERGECOPY.
DSNU463I 199 10:37:11.37 DSNUYBR3 - THE PRIMARY IMAGE COPY DATA SET SETEMP.R510D0DC.R510S81.P0000.D17198.T1025 WITH
DATE=170717 AND TIME=102429
IS PARTICIPATING IN MERGECOPY.
DSNU463I 199 10:37:11.43 DSNUYBR3 - THE PRIMARY IMAGE COPY DATA SET SETEMP.R510D0DC.R510S81.P0000.D17198.T1235 WITH
DATE=170717 AND TIME=123501
IS PARTICIPATING IN MERGECOPY.
DSNU463I 199 10:37:11.48 DSNUYBR3 - THE PRIMARY IMAGE COPY DATA SET SETEMP.R510D0DC.R510S81.P0000.D17111.A10756 WITH
DATE=170421 AND TIME=075641
IS PARTICIPATING IN MERGECOPY.
DSNU030I 199 10:37:11.50 DSNUYBR3 - UNABLE TO ALLOCATE SETEMP.R510D0DC.R510S81.P0000.D17111.A10756, RC=4,
CODE=X'17080002'
DSNU454I 199 10:37:11.63 DSNUYBR0 - COPY MERGE COMPLETE
NUMBER OF COPIES=4
NUMBER OF COPIES MERGED=3
TOTAL NUMBER OF PAGES MERGED=363
ELAPSED TIME=00:00:00
DSNU010I 199 10:37:11.67 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4Look again
Did you see what went wrong? No, nor did I the first time! Review again…
When a Return Code = 04 is actually important
Now do you see it?
DSNU030I 199 10:37:11.50 DSNUYBR3 - UNABLE TO ALLOCATE
SETEMP.R510D0DC.R510S81.P0000.D17111.A10756, RC=4,
CODE=X'17080002'Hidden amongst all the other output…and “only” a RC=4 !
So? What does that have to do with me?
Well, who checks RC=04? Your data is non-recoverable, but you *think* you are green! Pretty nasty if you ask me! Db2 does get a bonus point though for actually merging the incrementals into another incremental…
2 – MODIFY Recovery
DSNUM ALL gone forever?
Remember the bad old days, when you *had* to take a TS level Image Copy of partitioned objects when you REORGed them?
Wasn’t that a terrible time? Terabytes of disk space pointlessly being filled with needless image copy data. Then along came Db2 11, which enabled TP level copies! Hoorah! Ok, not so hot with tapes etc. but who cares, it worked! Finally, we did not need to keep *huge* DSNUM ALL style copies lounging around on our expensive disks.
Too good to be true?
All sounds good, huh? What did we forget? I will tell you… NPSIs (The indexes formally known as NPIs) What is the problem, I hear you shout! Well, let me walk you through a normal scenario with COPY YES indexes…
Keep it Simple Stupid
Let us imagine a little tablespace with two partitions, one DPSI and two NPSIs. All of the indexes are COPY YES. Due to the fact that we now only do INLINE COPYs at the TP level, SYSCOPY gets lots of records looking like this:
| Space | Part | Type |
| TP | 1 | F |
| IP | 1 | F |
| TP | 2 | F |
| IP | 2 | F |
| NPSI1 | 0 | F |
| NPSI2 | 0 | F |
| Then a day later | ||
| TP | 2 | F |
| IP | 2 | F |
| NPSI1 | 0 | F |
| NPSI2 | 0 | F |
| Then another day later | ||
| TP | 2 | F |
| IP | 2 | F |
| NPSI1 | 0 | F |
| NPSI2 | 0 | F |
Remember that the NPSIs are copied with the DPSIs.
Time to DELETE the old data
Now, using MODIFY RECOVERY, you wish to rid yourself of the oldest data from Part 2.
A nice little
MODIFY RECOVERY TABLESPACE DB.TP DSNUM 2 RETAIN LAST(1)
Is enough. However, as it says in the documentation, this form does *not* delete NPSI data.
COPY PEND is not your friend!
If you use the DSNUM ALL, which *will* delete the NPSI data, then it will most probably put the entire table space into COPY PEND, which you do *not* want!
Space is the problem
So now the problem begins to appear… imagine that this has been happening for a year or more… you now have hundreds of syscopy entries *and* datasets for NPSI data that you cannot simply, or easily, MODIFY “away” anymore!
What I think is needed, is a new parameter, say “INCLUDE NPSI”, which will also get rid of NPSI data. RFE anyone??
I have no fix for this problem either, except to actually take a DSNUM 0 copy, including all indexes, and then do DSNUM ALL style MODIFY RECOVERY. Pretty messy…
As usual, if you have any comments or queries please feel free to drop me a line!
TTFN
Roy Boxwell