This month I want to have a good look inside the SYSLGRNX – Not just for fun, but actually to review what is inside and ask the question: Is any of it “interesting” for us as DBAs?
Create your own?
Since Db2 10 the Db2 Directory table SYSIBM.SYSLGRNX has been available for normal SQL use. I wrote a newsletter all about this (Discovering hidden recovery problems in the SYSLGRNX.) This “older” newsletter has now been updated with a newer version of the SYSLGRNX private table/index and how to cross load it and RUNSTATS it, which we will be using within this newsletter.
What is it?
The SYSLGRNX table is used by Db2 to “remember” when a physical page set (object) changed from R/O access to R/W access. This is a requirement to speed up RECOVER jobs. When this is done correctly, the RECOVER can simply look in SYSLGRNX to find any RBA/LRSN ranges that must actually be checked in the Db2 Log. Without this table, Db2 would *have* to access all the logs from the last Full Image Copy/Incremental Image Copy to see if any data changes had been done. This means that the table is pretty critical when it comes to doing a RECOVER job!
Why look in it?
Well, it is nice to know that Db2 is keeping tabs on everything, but what if it makes a mistake? Heaven forbid there could be bugs in the code or perhaps an LPAR crash… Basically, it boils down to a good chance that you have some garbage in the table. This does not have any impact at all *until* you try and RECOVER an object… then Db2 requires an archive log from 2017 and the object is marked as “unrecoverable” – Whoops!
SQL Time – LRSN or RBA Sir?
So now you have to decide: are you interested in data sharing (DS) or in non-data sharing (Non-DS) systems? DS use the Log Record Sequence Number (LRSN) to mark data on the log. It is basically a ten-byte super-duper timestamp field, with/without an offset, which points to a place on the log. If Non-DS, you use a Relative Byte Address (RBA) which is really just a ten-byte address pointing to a place on the log. All of the sample SQL assumes you are running in a DS world and that you have created the updated private version of SYSLGRNX.
Start with Open Units of Work
Let’s have a quick review of all current Open Units of Work (OUW) that exist:
-- OPEN UNITS OF WORK IN SYSLGRNX
SELECT L.LGRDBID AS DBID
,SUBSTR(TS.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(TS.NAME, 1, 8) AS SPACE
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,'TS'
,L.LGRMEMB AS DM
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSTABLESPACE TS
WHERE TS.DBID = L.LGRDBID
AND TS.PSID = L.LGRPSID
--AND HEX(L.LGRSPBA) = '00000000000000000000'
AND HEX(L.LGRELRSN) = '00000000000000000000'
UNION ALL
SELECT L.LGRDBID AS DBID
,SUBSTR(IX.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(IX.INDEXSPACE, 1, 8) AS SPACE
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,'IX'
,L.LGRMEMB AS DM
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSINDEXES IX
WHERE IX.DBID = L.LGRDBID
AND IX.ISOBID = L.LGRPSID
--AND HEX(L.LGRSPBA) = '00000000000000000000'
AND HEX(L.LGRELRSN) = '00000000000000000000'
ORDER BY 7
WITH UR
;
This SQL is written for DS. To convert to Non-DS just comment out the LRSN lines and uncomment out the RBA lines not forgetting the WHERE statements!
An OUW is one where the Stop RBA/End LRSN is not yet filled (so all zeroes), by the way. These are all “in use” objects and I have seen ranges from six to 17,000 of these. The Stop RBA / End LRSN is updated when the page set gets pseudo, or physically, closed again. How many of these you can/should have all depends on your workload, your choice of ZPARM PCLOSEN and when you copy the SYSLGRNX of course.
Here on my test system I only get these:
---------+---------+---------+---------+---------+---------+---------+---------+
DBID DBNAME ID NEG_PSID SPACE PART LGRX_UCTIMESTAMP
---------+---------+---------+---------+---------+---------+---------+---------+
6 DSNDB06 2210 N SYSTSTSS 1 2020-07-29-13.53.27.740000
6 DSNDB06 2208 N SYSTSISS 1 2020-08-26-12.46.56.690000
6 DSNDB06 2068 N SYSTSPKG 1 2020-08-26-13.46.57.710000
6 DSNDB06 2018 N SYSTSDBA 1 2020-08-26-14.13.13.310000
6 DSNDB06 371 N SYSSEQ 0 2020-08-26-14.13.13.310000
6 DSNDB06 1994 N SYSTSCOL 1 2020-08-26-14.13.13.320000
6 DSNDB06 2014 N SYSTSTAB 1 2020-08-26-14.13.13.320000
6 DSNDB06 2016 N SYSTSTSP 1 2020-08-26-14.13.13.320000
6 DSNDB06 2012 N SYSTSTPT 1 2020-08-26-14.13.13.320000
6 DSNDB06 2020 N SYSTSDBU 1 2020-08-26-14.13.13.320000
6 DSNDB06 2010 N SYSTSTAU 1 2020-08-26-14.13.13.340000
505 DSN00171 2 N SYSLGRNX 1 2020-08-26-14.13.33.340000
DSNE610I NUMBER OF ROWS DISPLAYED IS 12
But here you can see there is something odd in that first row! I do not believe we have an OUW from July as it is the end of August at time of writing.
Grouping the output
Now to get a view of how many records per object you have. With this output you can instantly see where you have *way* too many records and need at least a MODIFY RECOVERY and/or a full image copy!
-- GROUP RECORDS IN SYSLGRNX
SELECT L.LGRDBID AS DBID
,SUBSTR(TS.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(TS.NAME, 1, 8) AS SPACE
,L.LGRPART AS PART
,MIN(L.LGRUCTS) AS MIN_LGRX_UCTIMESTAMP
,MAX(L.LGRUCTS) AS MAX_LGRX_UCTIMESTAMP
-- ,MIN(HEX(L.LGRSRBA)) AS MIN_START_RBA
-- ,MAX(HEX(L.LGRSRBA)) AS MAX_START_RBA
-- ,MIN(HEX(L.LGRSPBA)) AS MIN_END_RBA
-- ,MAX(HEX(L.LGRSPBA)) AS MAX_END_RBA
,MIN(HEX(L.LGRSLRSN)) AS MIN_START_LRSN
,MAX(HEX(L.LGRSLRSN)) AS MAX_START_LRSN
,MIN(HEX(L.LGRELRSN)) AS MIN_END_LRSN
,MAX(HEX(L.LGRELRSN)) AS MAX_END_LRSN
,'TS'
,COUNT(*)
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSTABLESPACE TS
WHERE TS.DBID = L.LGRDBID
AND TS.PSID = L.LGRPSID
--AND NOT L.LGRSRBA = L.LGRSPBA
AND NOT L.LGRSLRSN = L.LGRELRSN
GROUP BY L.LGRDBID
, TS.DBNAME
, L.LGRPSID
, L.LGRNEGPSID
, TS.NAME
, L.LGRPART
UNION ALL
SELECT L.LGRDBID AS DBID
,SUBSTR(IX.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(IX.INDEXSPACE, 1, 8) AS SPACE
,L.LGRPART AS PART
,MIN(L.LGRUCTS) AS MIN_LGRX_UCTIMESTAMP
,MAX(L.LGRUCTS) AS MAX_LGRX_UCTIMESTAMP
-- ,MIN(HEX(L.LGRSRBA)) AS MIN_START_RBA
-- ,MAX(HEX(L.LGRSRBA)) AS MAX_START_RBA
-- ,MIN(HEX(L.LGRSPBA)) AS MIN_END_RBA
-- ,MAX(HEX(L.LGRSPBA)) AS MAX_END_RBA
,MIN(HEX(L.LGRSLRSN)) AS MIN_START_LRSN
,MAX(HEX(L.LGRSLRSN)) AS MAX_START_LRSN
,MIN(HEX(L.LGRELRSN)) AS MIN_END_LRSN
,MAX(HEX(L.LGRELRSN)) AS MAX_END_LRSN
,'IX'
,COUNT(*)
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSINDEXES IX
WHERE IX.DBID = L.LGRDBID
AND IX.ISOBID = L.LGRPSID
--AND NOT L.LGRSRBA = L.LGRSPBA
AND NOT L.LGRSLRSN = L.LGRELRSN
GROUP BY L.LGRDBID
, IX.DBNAME
, L.LGRPSID
, L.LGRNEGPSID
, IX.INDEXSPACE
, L.LGRPART
ORDER BY 14 DESC
WITH UR
;
Again, this is a DS version – same rules apply as the first SQL and, in fact, for all following SQL as well!
Output looks like:
---------+---------+---------+---------+---------+---------+---------+---------+
DBID DBNAME ID NEG_PSID SPACE PART MIN_LGRX_UCTIMESTAMP
---------+---------+---------+---------+---------+---------+---------+---------+
6 DSNDB06 2208 N SYSTSISS 1 2019-09-28-15.02.57.790000
6 DSNDB06 2210 N SYSTSTSS 1 2019-09-28-15.02.57.780000
6 DSNDB06 2068 N SYSTSPKG 1 2019-09-28-13.51.16.650000
6 DSNDB06 2228 N SYSTSSFB 1 2019-09-28-15.02.58.840000
6 DSNDB06 2010 N SYSTSTAU 1 2019-09-28-13.51.18.800000
348 MVNXTEST 352 N MVNXS89 1 2020-03-11-07.21.38.830000
1 DSNDB01 127 N SPT01 1 2019-09-28-13.51.16.620000
-------+---------+---------+---------+---------+---------+---------+--
MAX_LGRX_UCTIMESTAMP MIN_START_LRSN MAX_START_LRSN
-------+---------+---------+---------+---------+---------+---------+--
2020-08-26-12.46.56.690000 00D6CADBE78BCD209000 00D86990DB7295A35400
2020-07-29-13.53.27.740000 00D6CADBE77162E15600 00D84A37CE9CCF71C400
2020-08-26-13.46.57.710000 00D6CACBE16C6D6D2800 00D867213DA095E82400
2020-08-26-09.16.50.090000 00D6CADBE7FB6E5FCC00 00D8670666C5C4344600
2020-08-26-14.13.13.340000 00D6CACBE2DBBC140000 00D866E87FD0328A4600
2020-07-02-08.42.53.340000 00D7A00B986CE7398600 00D82800085E355D1800
2020-08-26-10.18.22.240000 00D6CACBE1285CB92800 00D866E87F9F228F0A00
-----+---------+---------+---------+---------+---------+---
MIN_END_LRSN MAX_END_LRSN
-----+---------+---------+---------+---------+---------+---
00D6CADE5D36D0BD2000 00000000000000000000 TS 22519
00D6CADE5D34CB2B6C00 00000000000000000000 TS 21092
00D6CACCE2EF932A2400 00000000000000000000 TS 698
00D6CADE5D381865B400 00D86710F530EDF11800 TS 568
00D6CACCE2F4C7A05800 00000000000000000000 TS 487
00D7A00A120AD792D800 00D8280A9A34E82F9800 TS 450
00D6CACCE344A2021200 00D866F33992A0EDD600 TS 448
Here you can see that the RTS tablespaces are in desparate need of a Full Image Copy and a MODIFY RECOVER! I hope you have no numbers as high as mine!
Oh, for the poor orphans
Yes indeed, orphans also exist in Db2 SYSLGRNX sometimes… Run this SQL to check:
-- ORPHAN RECORDS IN SYSLGRNX - SHOULD BE NONE
SELECT L.LGRDBID AS DBID
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,L.LGRMEMB AS DM
FROM BOXWELL.SYSLGRNX2 L
WHERE NOT EXISTS
(SELECT 1
FROM SYSIBM.SYSTABLESPACE TS
WHERE TS.DBID = L.LGRDBID
AND TS.PSID = L.LGRPSID
)
AND NOT EXISTS
(SELECT 1
FROM SYSIBM.SYSINDEXES IX
WHERE IX.DBID = L.LGRDBID
AND IX.ISOBID = L.LGRPSID
)
ORDER BY LGRX_UCTIMESTAMP
WITH UR
;
In my DS there are none, but when I run in my non-DS system I get:
---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+----
DBID ID NEG_PSID PART LGRX_UCTIMESTAMP START_RBA END_RBA
---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+----
414 2 N 1 2020-01-06-13.31.11.100000 00000000008EB1D404EC 00000000008EB1D419EC
414 2 N 1 2020-01-06-13.31.11.110000 00000000008EB1D438A7 00000000008EB1D49074
Now I happen to remember this! A colleague was “playing” with CLONE Objects and caused a bit of a problem back in the first week of the year… I have to now figure out how to get rid of these bad boys really…REPAIR should do it for me, but in a productive system I would probably contact IBM for assistance.
SYSLGRNX for Dummies?
You may have noticed that in most of the queries there is a predicate:
--AND NOT L.LGRSRBA = L.LGRSPBA
AND NOT L.LGRSLRSN = L.LGRELRSN
So, the question is: What??? Why would the SYSLGRNX have entries where the Start RBA was equal to the Stop RBA or the Start LRSN was equal to the End LRSN? These are special “events” or the so-called “dummy” entries. To see how many you have, run this little query:
-- SPECIAL/DUMMY ENTRIES IN SYSLGRNX
SELECT L.LGRDBID AS DBID
,SUBSTR(TS.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(TS.NAME, 1, 8) AS SPACE
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,'TS'
,L.LGRMEMB AS DM
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSTABLESPACE TS
WHERE TS.DBID = L.LGRDBID
AND TS.PSID = L.LGRPSID
AND L.LGRSLRSN = L.LGRELRSN
--AND L.LGRSRBA = L.LGRSPBA
UNION ALL
SELECT L.LGRDBID AS DBID
,SUBSTR(IX.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(IX.INDEXSPACE, 1, 8) AS SPACE
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,'IX'
,L.LGRMEMB AS DM
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSINDEXES IX
WHERE IX.DBID = L.LGRDBID
AND IX.ISOBID = L.LGRPSID
AND L.LGRSLRSN = L.LGRELRSN
--AND L.LGRSRBA = L.LGRSPBA
ORDER BY 7
WITH UR
;
I get data like this here on my test DS system:
---------+---------+---------+---------+---------+---------+---------+---------+
DBID DBNAME ID NEG_PSID SPACE PART LGRX_UCTIMESTAMP
---------+---------+---------+---------+---------+---------+---------+---------+
320 R510D0DE 122 N R510S23 1 2019-09-30-07.53.56.670000
320 R510D0DE 122 N R510S23 1 2019-09-30-07.53.58.880000
348 MVNXTEST 122 N MVNXS23 1 2019-11-07-11.24.59.920000
348 MVNXTEST 122 N MVNXS23 1 2019-11-07-11.24.59.950000
348 MVNXTEST 389 N MVNXS001 1 2019-11-07-14.48.37.780000
348 MVNXTEST 389 N MVNXS001 1 2019-11-07-14.48.38.890000
348 MVNXTEST 398 N MVNXS002 1 2019-11-07-14.48.40.050000
348 MVNXTEST 398 N MVNXS002 1 2019-11-07-14.48.40.090000
348 MVNXTEST 429 N MVNXS007 1 2019-11-07-14.48.42.200000
348 MVNXTEST 389 N MVNXS001 1 2020-02-21-11.25.54.480000
348 MVNXTEST 389 N MVNXS001 1 2020-02-21-11.25.55.560000
348 MVNXTEST 398 N MVNXS002 1 2020-02-21-11.25.56.680000
348 MVNXTEST 398 N MVNXS002 1 2020-02-21-11.25.57.700000
-------+---------+---------+---------+---------+------
START_LRSN END_LRSN DM
-------+---------+---------+---------+---------+------
00D6CCFFBDC159BB2E00 00D6CCFFBDC159BB2E00 TS 2
00D6CCFFBFC00FF01200 00D6CCFFBFC00FF01200 TS 2
00D6FCF5C92F2D4F5200 00D6FCF5C92F2D4F5200 TS 2
00D6FCF5C976B5E74600 00D6FCF5C976B5E74600 TS 2
00D6FD234DC040BFE200 00D6FD234DC040BFE200 TS 1
00D6FD234EBD47CE8400 00D6FD234EBD47CE8400 TS 1
00D6FD235042B0392800 00D6FD235042B0392800 TS 2
00D6FD2350B1394C5800 00D6FD2350B1394C5800 TS 2
00D6FD2351B0B0B72A00 00D6FD2351B0B0B72A00 TS 2
00D7823BB0FED94EA800 00D7823BB0FED94EA800 TS 1
00D7823BB1C7253F4A00 00D7823BB1C7253F4A00 TS 1
00D7823BB2F61E0A3400 00D7823BB2F61E0A3400 TS 2
00D7823BB32BFC34CE00 00D7823BB32BFC34CE00 TS 2
What I can see from this, is that for any DDL CREATE with LOGGED attribute, or any LOAD REPLACE LOG(NO) utility, you get an entry that you can also find in SYSCOPY. The RECOVER utility might well need this data as well if you are rolling forward.
The oldest are the bestest!
Finally, a simple “review” of the SYSLGRNX data sorted by LGRNX_UCTIMESTAMP. Just so you get an overview, this SQL has a FETCH FIRST 500 ONLY but feel free to change that number!
-- OLDEST VALID RECORDS IN SYSLGRNX
SELECT L.LGRDBID AS DBID
,SUBSTR(TS.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(TS.NAME, 1, 8) AS SPACE
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,L.LGRMEMB AS DM
,'TS'
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSTABLESPACE TS
WHERE TS.DBID = L.LGRDBID
AND TS.PSID = L.LGRPSID
--AND NOT L.LGRSRBA = L.LGRSPBA
AND NOT L.LGRSLRSN = L.LGRELRSN
UNION ALL
SELECT L.LGRDBID AS DBID
,SUBSTR(IX.DBNAME, 1, 8) AS DBNAME
,L.LGRPSID AS ID
,L.LGRNEGPSID AS NEG_PSID
,SUBSTR(IX.INDEXSPACE, 1, 8) AS SPACE
,L.LGRPART AS PART
,L.LGRUCTS AS LGRX_UCTIMESTAMP
-- ,HEX(L.LGRSRBA) AS START_RBA
-- ,HEX(L.LGRSPBA) AS END_RBA
,HEX(L.LGRSLRSN) AS START_LRSN
,HEX(L.LGRELRSN) AS END_LRSN
,L.LGRMEMB AS DM
,'IX'
FROM BOXWELL.SYSLGRNX2 L
,SYSIBM.SYSINDEXES IX
WHERE IX.DBID = L.LGRDBID
AND IX.ISOBID = L.LGRPSID
--AND NOT L.LGRSRBA = L.LGRSPBA
AND NOT L.LGRSLRSN = L.LGRELRSN
ORDER BY LGRX_UCTIMESTAMP
FETCH FIRST 500 ROWS ONLY
WITH UR
;
Here you can see that I rarely ever image copy the Db2 catalog…
---------+---------+---------+---------+---------+---------+---------+---------+
DBID DBNAME ID NEG_PSID SPACE PART LGRX_UCTIMESTAMP
---------+---------+---------+---------+---------+---------+---------+---------+
6 DSNDB06 2002 N SYSTSIPT 1 2019-09-28-13.45.32.200000
6 DSNDB06 2000 N SYSTSIXS 1 2019-09-28-13.45.32.250000
6 DSNDB06 2016 N SYSTSTSP 1 2019-09-28-13.46.59.970000
6 DSNDB06 2012 N SYSTSTPT 1 2019-09-28-13.46.59.970000
6 DSNDB06 2034 N SYSTSSTG 1 2019-09-28-13.48.02.210000
1 DSNDB01 148 N DSNSPT02 0 2019-09-28-13.51.16.620000
-------+---------+---------+---------+---------+------
START_LRSN END_LRSN DM
-------+---------+---------+---------+---------+------
00D6CACA98D8486B6C00 00D6CACCE2F5E2B14600 1 TS
00D6CACA99560741CC00 00D6CACCE2F9B5CCD800 1 TS
00D6CACAEC7D724A9600 00D6CACCE2F31722C800 1 TS
00D6CACAEC7C8EA08A00 00D6CACCE2F7C7553800 1 TS
00D6CACB27FFD7A40200 00D6CACCE2F214B70E00 1 TS
00D6CACBE127037D0A00 00D6CACCE31529801400 1 IX
00D6CACBE1279F5EA000 00D6CACCE31662377800 1 IX
What’s in a name?
Looking at the outputs you can see the NEG_PSID column. This is set based on whether or not the original PSID in the SYSLGRNX was negative or not. If it is negative it means you are dealing with a CLONE object, so buyer beware on those entries!
The DM column is the Data-sharing member number, it is 0 (zero) for Non-DS and 1 to 32 for DS systems. Sometimes you can get a clue about why an entry is there when you can link it to a member. Use the -DISPLAY GROUP command to get the number for your member:
DSN7100I -SC10 DSN7GCMD
*** BEGIN DISPLAY OF GROUP(GSC10C11) CATALOG LEVEL(V12R1M505)
CURRENT FUNCTION LEVEL(V12R1M505)
HIGHEST ACTIVATED FUNCTION LEVEL(V12R1M505)
HIGHEST POSSIBLE FUNCTION LEVEL(V12R1M506)
PROTOCOL LEVEL(2)
GROUP ATTACH NAME(SC1 )
---------------------------------------------------------------------
DB2 SUB DB2 SYSTEM IRLM MEMBER ID SYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC
-------- --- ---- -------- -------- ------ -------- ---- --------
MEMSC10 1 SC10 -SC10 ACTIVE 121507 S0W1 JC10 SC10IRLM
MEMSC11 2 SC11 -SC11 QUIESCED 121507 S0W1 JC11 SC11IRLM
---------------------------------------------------------------------
Here the ID column is the member number. It is possible you might have DM ids for members that no longer exist… these must also be cleared out as well!
As always, any questions or comments would be most welcome!
TTFN,
Roy Boxwell