2026-07 Are you Quantum Safe?

Quantum is being really heavily hyped at the moment and even my good self has been caught up in some of the Hoo-ha around it! Specifically which parts of Db2 are not “quantum safe”?

Quantum?

Yep, not like the TV Series “Quantum Leap” at all! The idea of quantum data goes back many, many decades but has only recently really started earning a living instead of being a scientific curiosity! There are six basic concepts that you must know a little about to start to “grasp the basics” of Quantum Computing.

Have you Qubit off more than you can chew?

The most important bit about quantum computers is the fact that they have qubits and not bits! The difference is staggeringly huge and mind-bendingly weird but boils down to the simple fact that a bit can be 0 (off) or 1 (on) – That’s it folks! On the other hand, a qubit can be anywhere between 0 (off) and 1 (on), in fact an infinite number, and it gets weirder when you have more qubits to play with. They do not join linearly but exponentially! This means that with 1,024 Qubits you have a mind-meltingly high number of possible values.

Ice Ice Baby!

You gotta keep qubits cold and I mean really cold… best is 0o Kelvin (Absolute zero) which is pretty nippy in July! For me in Germany that is -273.15o Celsius and for those of you “over the pond” a very large negative number of Fahrenheit! Ok, the actual number is -459.67o Fahrenheit. Naturally, we never can reach 0o Kelvin but we can get pretty close these days and at this temperature it minimizes error rates and enables superconducting behavior as well. The warmer they get the more they are prone to losing their quantum state, or decoherence in the jargon.

Superposition – the first Concept

Qubits are in a superposition of all possible values between 0 and 1 until they are measured. Then they snap back, the quantum state collapses is the correct term, and resolve to a 0 or 1 – This gives you the “answer” if you like. We can never fully predict the outcome but we can calculate the probability of a given outcome.

Entangled – the second Concept

Entanglement is crucial to getting Quantum computers to do any meaningful work for us humans. It is, at a minimum, two particles that are paired up in such a way that the quantum state of one particle cannot be determined independently of the state of the other, irrespective of the distance between the two. In other words, you can work out the quantum state of a particle when it is a light year away from its partner! Einstein famously wrote in 1947 about “spukhafte Fernwirkung”, in English “spooky action at a distance” as he could not believe this! But it has now been proven over and over that entanglement does happen and with many more than just two qubits.

Exponential speed-up?

Using entanglement puts two or more qubits into a single shared quantum state, so they stop behaving independently and combined with interference (coming up) that is where the real speed-up lives. Please also remember that measuring one does instantly pin down the others, but no usable information actually travels faster than light. For one qubit we have probabilities distributed over two states. For two qubits the distribution goes over four states, for three qubits it is eight states etc. In general, the rule is for N qubits the probability is over 2n states.

Interference – the third Concept

We have all thrown stones into a pond or the sea and seen the ripples spread outwards. When the waves bounce back from the edge of a wall or boat you might have noticed that the waves interact with each other. When the peaks meet, you get a big wave. When troughs meet, you get a big hole. And when a peak meets a trough – nothing.

Give us a Wave!

In the quantum world this a wave function which is a mathematic description based on polynomials. To measure the entangled qubits, you just add the individual wave functions for every qubit until you have a single wave function of a single quantum state. This adding of the wave function gives us an interference pattern where we can change probabilities of the correct answer by using constructive interference (The peaks of the wave add up) or reduce the probability of a wrong answer by using destructive interreference (Where the two waves cancel each other out).

Tunneling – the fourth Concept

Now it gets weird! (Only now, you ask? Well …) This is where an object can pass through an energy barrier that within normal classical physics it should not be able to pass through! Think of a high mountain and then imagine that someone has bored a tunnel at the base of the mountain right on through. If the object can use the tunnel, it will make it much faster to the other side! Remember, the wave function is a probability so when this function encounters a potential barrier and if the barrier is thin enough it can indeed tunnel through and then there is a chance that the particle will appear on the other side.

Examples abound!

Nuclear fusion in stars is where protons overcome their electrostatic repulsion which allows the sun to shine, or radioactive decay where Alpha particles tunnel out of the nucleus. Modern electronics rely on this phenomena for tunnel diodes which were invented in 1957, for scanning tunneling microscopes invented in 1981 and also for flash memory as well.

Synchronization – the fifth Concept

We have all been to concerts where people start clapping. At some point all the clapping synchronizes and gets very loud! This is where the wave functions of independent particles can all “march to the same beat” and spontaneously synchronize – this is very important when using certain algorithms.

Quantum Parallelization – the sixth Concept

Behind this is the really weird idea of parallel universes where each universe does one calculation and with N parallel universes the time of one calculation is enough for *all* calculations. At the moment of “observation” the qubit ends in a “collapsed” state and you get a result. This is also used in quantum chip design where the second, or more, input can be influenced by the first input!

The Traveling Salesman gets his Route!

The Traveling Salesman is a very old problem, from 1930, where you must calculate the optimal route for a poor traveling salesman to visit N cities with the shortest route, visit each city only once and return to the starting city. It sounds “easy” but is actually NP-Hard. In math terms this means it is not solvable in polynomial time and for every city added the time goes up exponentially. If you have three cities anyone can do it but when you have just 20 it gets practically unsolvable!

Give me numbers!

A raw brute force “try every possible route” approach takes a running time within a polynomial factor of O(n!) where O is the Order of growth in Landau notation – fittingly, it comes from the German word “Ordnung” (Order). So you can see that after 20 Cities the numbers get silly. The Held-Karp algorithm from 1962 solves it in time O(N22N) whereas the latest quantum algorithm from Ambainis et al. from 2019 runs in just O(1.728N).

CitiesBrute ForceHeld-KarpQuantum
36725
103,628,800102,400237
202.43 x 1018419,430,40056,347

As you can clearly see, Quantum Computers will greatly help with this problem and all derivatives in logistics, and DNA sequencing, for example. Note that the quantum solution is still exponential but just not as bad as before as it is a NP-Hard problem after all!

Spinning on your Heels?

To get this level of improvement the Quantum Computer uses an Ising Machine where spinning particles are each a city and they will eventually all synchronize on the most efficient path. Calibration is on various factors but for the Traveling Salesman problem it is on distance.

Now we are Experts – Why?

Factoring of numbers is the number one reason, as of today, for doing all this! But, unlike the Traveling Salesman, factoring is not actually NP-Hard – it sits in a curious middle ground, and it is exactly that hidden structure a quantum computer can exploit (quantum computers are not believed to crack genuine NP-Hard problems). Encryption is basically two large prime numbers multiplied together. Computers can do that very easily! Going back, or factoring, from a huge semi-prime number to the two starting primes is, however, very difficult for a classic computer. Shor’s algorithm lets a quantum computer recover those prime factors efficiently – not by trying everything at once, but by exploiting interference – and that breaks the public-key (asymmetric) encryption such as RSA and ECC which protects key exchange and digital certificates.

Grover’s Algorithm

Lov Grover created this in 1996 and it is basically an enhanced search with O(√N) evaluations but it can brute-force a 128-bit key in 264 iterations or 256-bit in 2128 iterations. It is quadratically better than simple brute-force and there are improvements on their way – especially the class of non-local hidden variable quantum computers could do the search in O(∛N) – the cube root of N – evaluations instead of O(√N) evaluations!

Finally Db2!

Yeah! I made it nearly to the end before even getting into the reason for the newsletter!!! The problem is that all of our data is encrypted, most of you are using 128-bit keys which are ok and are still pretty hard to crack. Anything less than 128-bit keys is crackable now in a brute force attack. The recommended way forward and to remain “Quantum Safe” is to change all your encryption today to use at least 256-bit keys. These will be safe from Quantum Computers for a long time.

Post-quantum…

One nuance worth stating plainly: the Db2 ENCRYPT and HASH functions listed below are symmetric, where a quantum computer (Grover) only halves the effective key strength – so moving to 256-bit gives you 128-bit of real protection and is exactly the right fix here. The factoring threat from Shor described above instead breaks asymmetric public-key crypto such as RSA and ECC, where larger keys do not help and post-quantum algorithms are required – that protects your TLS handshakes and certificates and is a separate piece of work.

How long is long?

The so-called Q-Day is expected in 2030 when anyone with a Quantum Computer can then read all the data you are *now* storing…  

Stuff to do, then?

Yes indeed, any use of the following is no longer really secure for “tomorrow” anymore and steps must be taken to raise the level of encryption. If any of the following scalar functions are being used in your shops it is time to start a project group “Quantum Safe Encryption”:

DECRYPT_BINARY
DECRYPT_BIT
DECRYPT_CHAR
DECRYPT_DB
ENCRYPT           Triple Data Encryption Standard 128 Bits
ENCRYPT_TDES      Triple Data Encryption Standard 128 Bits
HASH(xxxx)        Message Digest 5                128 Bits
HASH(xxxx,0)      Message Digest 5                128 Bits
HASH(xxxx,1)      Secure Hash Algorithm 1         160 Bits
HASH_CRC32(xxxx)  Cyclic Redundancy Check          32 Bits
HASH_MD5(xxxx)    Message Digest 5                128 Bits
HASH_SHA1(xxxx)   Secure Hash Algorithm 1         160 Bits

Replacements, please!

If you find any of these in your SQL workload you must get the application teams to replace them with:

DECRYPT_DATAKEY_type     With the new full list of types.
ENCRYPT_DATAKEY(xxxx,
key-label-name,
AES256R or AES256D)      All 256 Bits. Using AES256D enables EQUAL
                         usage as the same value will encrypt to the
                         same encrypted value but is not as secure
                         as AES256R.
HASH(xxxx,2)             Secure Hash Algorithm 2 with 256 Bits
HASH_SHA256(xxxx)        Secure Hash Algorithm 2 with 256 Bits

The highest Bits have it!

As you can see, anything less than 256-bit keys is nowadays not deemed “Quantum Safe” which means someone will be able to easily decode your emails, data, transactions, logs etc. when that Q-Day comes – and it may come sooner than you would think or like!

Not easy to do!

So now, if you find any of these functions you must decrypt the data and then re-encrypt the data with one of the 256-bit keys so you are “safe for a while” – Of course how long we will be “Quantum Safe” with 256-bit keys is a very open question indeed!

Finally a small course from IBM

Here’s a nice intro to all of the above from IBM.

TTFN,

Roy Boxwell

2026-06 Db2 vNext Migration – Are YOU ready, Player One?

This month I wish to stroll along the dangerous and difficult road called Db2 Release Migration. We all love it as it means a new release with all new go-faster features and whizzbang things to play with but we also all hate it as it means we have things to do before we can actually migrate and get to this new promised land.

With Db2 for z/OS vNext coming up soon we are now back in the Driving Seat!

The list of deprecated items is pretty long and now about 80% of them have been finally deleted. If you have, or use, any of them you will *not* be joining the rest of us on the other side of the valley where the grass is definitely much greener!

The list of killed off items is:

  • Simple tablespaces
  • Segmented tablespaces
  • Classic partitioned tablespaces (With or without Index based partitioning)
  • Basic (Six byte) format
  • BRF (Basic Row Format so not yet at RRF – Reordered Row Format)
  • Hash Access
  • Synonyms
  • VTAM/SNA

Haakon Roberts shared this data at the IDUG EMEA 2024 in Valencia and it was the first time we had all seen an inkling of what would come. The real surprise, at least for me, was the requirement to remove VTAM/SNA support and move over to TCP/IP. The rest we had all known about for years but killing off VTAM/SNA was brand new!

CATMAINT to the Rescue?

Nope! None of these features will be automagically fixed by running a CATMAINT. It is all manual work and up to us, the DBAs fighting at the front, to fix “When we have some spare time…”

An ALTER a Day keeps the Dr at Bay

The basic “cure” for most of these problem children is simply an ALTER and a REORG, but it *never* is that easy, is it? To fix segmented or simple tablespaces with just one table within them it is an ALTER to MAXPARTITIONS 1 which will kick the tablespace into the world of UTS PBG. Follow up with a REORG with inline statistics and a REBIND of all invalidated packages and you are done.

More than one?

If you have multi-table tablespaces then you must be at Db2 12 FL508 or higher and create a new set of tablespaces that match *exactly* the current ones for BUFFERPOOL, CCSID and LOGGED attributes. Then you use the ALTER … MOVE TABLE syntax for each table. An actioning REORG followed by a full RUNSTATS on each new tablespace afterwards with SHRLEVEL REFERENCE is then required to get the RTS statistics inline. Now do a REBIND of all invalidated packages and you are done.

Time for the Classics?

If you have any really, really old index-based partitioning tables, you must do two ALTERs within one commit scope. The first flipping the Partitioning Index to NOT CLUSTER and then back to CLUSTER. Now you are at table-based partitioning so read on!

Table-based partitioning

At this point it is an ALTER to SEGSIZE 64 which will kick these babies into the fun world of UTS PBR.

For both Classic cases, follow up with a REORG with inline statistics and a REBIND of all invalidated packages and you are done.

Six Byte RBA/LRSN, anyone?

If any of your tablespaces or indexspaces have not got 10 Byte RBA/LRSN then you must REORG them to action this. One little problem here is if the space is an XML space (Type = ‘P’) then you must first check its base table’s tablespace to see if that is a UTS space. If so then all is good, otherwise you have a non-versioning XML space which will require this four-step fix:

1. DSN1COPY to generate image copy for XML data

2. Drop XML column from base table

3. Recreate the XML column in the base table

4. LOAD REPLACE to load the XML data from the image copy generated by step 1.

Invalidated Packages?

Yup! All of these ALTERs and the actioning REORGs with their inline/afterwards RUNSTATS will happily invalidate any and all packages that refer to the objects… This is a major pain as your access paths can then very easily go south! This is time for our tool BindImpactExpert (BIX) to ride to the rescue. As long as you are running with EXPLAIN(YES) – and I sincerely hope you are!!! – BIX can be used to highlight any and all changed access paths enabling you to be proactive with corrective measures.

Definitely evil DEFINE NO

DEFINE NO objects are great as SQL can SELECT from them really fast! They take up next to no disk space and require no REORG or COPY processing as there is no VSAM dataset. The problem with these little devils is that REORG is actually *not* permitted on them! One exception to this rule is if the TS/TP was created with BRF, as then you can REORG with the option ROWFORMAT RRF and this REORG will just flip a bit or two in the catalog/directory and nothing else.

And???

That means that all the ALTERs you might have done are “hanging in the wind”. IBM state that an INSERT/LOAD will materialize the VSAM cluster(s) but who wants to do that? The only way forward is to extract the DDL that created them, DROP them and then reCREATE them all as DEFINE NO again. As when recreated they will be valid for vNext, of course then a REBIND of all invalidated packages is also required and you are done.

Devil in the Details

For BRF partitions the fixing REORG will fail if any table has a validation procedure (VALPROC table column) or edit procedure (EDPROC tabel column) defined. If this is the case then the procedures must first be dropped before the REORG and afterwards added back.

Did they make a HASH of it?

HASH access came in with a big fanfare, we finally had an access path like IMS HDAM, but it died a death very quickly and the fix here is ALTER with DROP ORGANIZATION. Naturally, this drops the hash index and so you must then create a new index for SQL use and – guess what else you must do? Of course, a REORG with inline statistics and a REBIND of all invalidated packages and you are done.

Simply SYNONYMs

I wrote a Blog about all these beasts.

Yes, over ten years ago! The actual fix for every synonym is straightforward:

SET CURRENT SQLID = 'Synonym schema' ;
DROP SYNONYM 'Synonym name' ;
  COMMIT ;
CREATE ALIAS 'Synonym schema'.'Synonym name'
       FOR   'Table creator'.'Table name' ;
  COMMIT ;

The problems here are that the statement SET CURRENT SQLID requires SYSADM Authorization, so this is not something I would farm out to the next student doing work experience!!! Plus, guess what you have to do afterwards??? A REBIND of all invalidated packages and possibly a chain of dependent invalidated objects as well and you are done.

TCP/IP is the Future!

It came as a surprise but there are indeed shops out there who are still using VTAM/SNA for inter-Db2 communication. The problem here is that when it was released in 1974, we all trusted each other! If you were connected to DB2A and just hopped over to DB2B it happily trusted you as you “were already on a DB2A so you must be good guy!” Sadly, those halcyon days are long gone. These days we have “Zero trust” as the norm – a real shame but it is what it is!

Reason for Change?

TCP/IP has enhanced security (AT-TLS and JSON Web Tokens), it can use 64-bit communication buffers and is zIIP eligible. You will save CPU and be much more secure, so going to this is really no question – However, this is a project all on its own – not something for a Friday afternoon at 4 o’clock!

Big Switch?

To switch off VTAM/SNA you should do several things. First clear out any and all old entries in the CDB tables LULIST, LUMODES, MODESELECT and all but the empty LUNAME entry from LUNAMES. Then you should do a BSDS update with DSNJU003 setting the IPNAME for that subsystem to be the real host name. Just doing that switches off VTAM/SNA for that member. If doing all this then also go to SECPORT usage at the same time as then your Db2s are truly secure! Your auditors will love you.

IBM Details

Are here.

Let’s get it sorted!

Yes, even all the sort workspaces must be cleaned-up and moved to PBG spaces. You really need a lot of 32k, a few 4k, and you need to know exactly how many FOR SORT and how many FOR DGTT (The new syntax in Db2 13 FL508) you require and need. No more guessing at which workload is going into which work tablespace.

  • FOR SORT specifies that the table space is used for processing other than declared global temporary table (DGTT) work, such as sort, joins, created global temporary tables, query parallelism, trigger transition tables, and so forth.
  • FOR DGTT specifies that the table space is used for DGTT work and processes that use internal temporary tables, such as scrollable cursors and INSTEAD OF triggers.

Remember that here no ALTER helps – you must DROP and CREATE the work spaces again… But hey! At least no REORG, RUNSTATS and REBINDs are required!

<PHEW> That’s a Ton of Stuff to do…

Wouldn’t it be cool if there was a nice small bit of freeware out there that listed out all the stuff you have to do to actually get ready for Db2 vNext! In fact, you cannot even get to Db2 13 FL511 as that will stop you with any of the above-mentioned items!

What Luck – SEGUS to the Rescue!

Yes indeed, we have a bit of freeware called MigrationReadiness HealthCheck for Db2 z/OS (MRHC) that runs through your Db2 subsystems and shows you all the KPIs you have as well as highlighting all the Migration Blockers, as I call them. There is also a pay-ware version that then actually creates all of the ALTERs, REORGS, RUNSTATS and REBINDs for you as well.

How does it look?

It looks cool, of course! Here are a few example screen grabs of how it looks in my little Db2 13 data-sharing test system and what it offers:

Db2 MigrationReadiness HealthCheck V2.1 for SD1 V13R1M509
               started at 2026-05-28-11.08.24
            Lines with *** are deprecated features                              
            Lines with MMM are migration blockers                               
            Lines with XXX are definition errors                                 
Number of DATABASES          :  225                                              
  # of empty DATABASES       :   48                                             
  # of implicit DATABASES    :  110                                              
  # of empty implicit DBs    :   46
                                              
Number of TABLESPACES        : 4995                                              
  of which HASH organized    :    0                                              
  of which PARTITION CLASSIC :    0                                              
    # Partitions             :    0                                              
  of which SEGMENTED         :   27 MMM                                          
  of which SIMPLE            :    3 MMM                                          
  of which LOB               :   99                                              
  of which UTS PBG           : 4833 
    # Partitions             : 4834                                              
  of which UTS PBR (Absolute):    1                                              
    # Partitions             :    6     
  of which UTS PBR (Relative):   10                                              
    # Partitions             : 2215                                              
  of which XML               :   22 
             
Number of TSs as LARGE       :    0                                              
Number of empty tablespaces  :    7                                              
Number of multi-table TSs    :   12 MMM                                          
  # of tables within these   :   49       
.
.
Number of table partitions   : 7211   
  of which DEFINE NO         : 2918   
  of which 6 byte RBA <11 NFM:    0   
  of which 6 byte RBA Basic  :    0   
  of which ten byte RBA      : 4293   
Number of TP in BRF          :   17 MMM
.
.
LULIST entries found         :    0   
LUMODES entries found        :    1 MMM
LUNAMES entries found        :    2 MMM
MODESELECT entries found     :    1 MMM
.
.
Total number of REORGs        21          
     REORGing                176 Cylinders
        also requiring      1409 REBINDs

   

Naturally, most of this is the Db2 Catalog and Directory. At the end it outputs a small list of KPIs with the Total number of REORGs required, the total numbers of Cylinders of space all the table and indexspaces take and how many REBINDs should then be done afterwards. This gives the experienced DBA a very good idea of how long and how potentially dangerous this whole thing could be!

Just the Facts, Ma’am!

Under DD card ALTERCAT in the pay-ware version are all the required actions, note that you must be at Db2 13 FL509 or above to get the CONVERTUTS REORG syntax:

-- REORG TABLESPACE DSNDB01.SCT02 SHRLEVEL CHANGE
--   CONVERTUTS 
-- REORG TABLESPACE DSNDB01.SYSUTILX SHRLEVEL CHANGE
--   CONVERTUTS 
-- REORG TABLESPACE DSNDB06.SYSALTER SHRLEVEL CHANGE
--   CONVERTUTS
-- REORG TABLESPACE DSNDB06.SYSCONTX SHRLEVEL CHANGE
--   CONVERTUTS 
--REBIND PACKAGE(IQA_COLLECTION_610.SQLDVDRC) APREUSE(WARN)       
--REBIND PACKAGE(IQA_COLLECTION_610.SQLDVDRC.(2026-01-21-06.55.23.099777)) APREUSE(WARN)
--REBIND PACKAGE(IQA_COLLECTION_DE.SQLDDLS.(2019-03-22-09.20.33.799998)) APREUSE(WARN)
--REBIND PACKAGE(IQA_COLLECTION_DE.SQLDDLS.(2022-08-01-06.08.43.796175)) APREUSE(WARN)
--REBIND PACKAGE(IQA_COLLECTION_DE.SQLDVCRC.(2018-08-21-07.21.16.927191)) APREUSE(WARN)
--REBIND PACKAGE(IQA_COLLECTION_DE.SQLDVDRC.(2022-08-01-06.21.52.371116)) APREUSE(WARN)
                                    

Notice that it always generates APREUSE(WARN) to try and keep the old access path.

Also, here are any of the nasty DEFINE NO REORG problems:

-- DEFINE NO TABLESPACE TS5941.TSTSDNQ REORG NOT POSSIBLE

and the SQL for CDB Clean-up:

-- DELETE FROM SYSIBM.LUMODES  
-- ;                           
-- COMMIT ;                    
-- DELETE FROM SYSIBM.LUNAMES  
-- WHERE NOT LUNAME = '        '
-- ;                           
-- COMMIT ;                    
-- DELETE FROM SYSIBM.MODESELECT
-- ;                           
-- COMMIT ;
  

Under DD card MIGRAREP are all the Migration Blockers listed out in detail:

Simple DB: DSNDB01 TS: SCT02      
Segmented DB: DSNDB01 TS: SYSUTILX
Segmented DB: DSNDB06 TS: SYSALTER
Segmented DB: DSNDB06 TS: SYSCONTX
Segmented DB: DSNDB06 TS: SYSDDF  
Segmented DB: DSNDB06 TS: SYSEBCDC
Simple DB: DSNDB06 TS: SYSGPAUT   
Segmented DB: DSNDB06 TS: SYSGRTNS
Segmented DB: DSNDB06 TS: SYSHIST 
Segmented DB: DSNDB06 TS: SYSJAVA 
Segmented DB: DSNDB06 TS: SYSROLES
Segmented DB: DSNDB06 TS: SYSSEQ  
Segmented DB: DSNDB06 TS: SYSSEQ2 
Segmented DB: DSNDB06 TS: SYSSTATS
Segmented DB: DSNDB06 TS: SYSTARG 
Segmented DB: DSNDB06 TS: SYSTSASC
Segmented DB: DSNDB06 TS: SYSTSUNI
Segmented DB: DSNDB06 TS: SYSTSXTM
Segmented DB: DSNDB06 TS: SYSTSXTS
Simple DB: DSNDB06 TS: SYSUSER    
Segmented DB: DSNDB06 TS: SYSXML  
Segmented DB: TS5941 TS: TSTSDNQ  
Segmented DB: WRKSD10 TS: DSN32K00
Segmented DB: WRKSD10 TS: DSN32K01
Segmented DB: WRKSD10 TS: DSN4K00 
Segmented DB: WRKSD10 TS: DSN4K01 
Segmented DB: WRKSD11 TS: DSN32K00
Segmented DB: WRKSD11 TS: DSN32K01
Segmented DB: WRKSD11 TS: DSN4K00 
Segmented DB: WRKSD11 TS: DSN4K01 
BRF tablespace DB: DSNDB01 TS: SCT02    
BRF tablespace DB: DSNDB01 TS: SYSUTILX 
BRF tablespace DB: DSNDB06 TS: SYSALTER 
BRF tablespace DB: DSNDB06 TS: SYSCONTX  
BRF tablespace DB: DSNDB06 TS: SYSDDF    
BRF tablespace DB: DSNDB06 TS: SYSEBCDC  
BRF tablespace DB: DSNDB06 TS: SYSGPAUT  
BRF tablespace DB: DSNDB06 TS: SYSGRTNS  
BRF tablespace DB: DSNDB06 TS: SYSHIST   
BRF tablespace DB: DSNDB06 TS: SYSJAVA   
BRF tablespace DB: DSNDB06 TS: SYSROLES  
BRF tablespace DB: DSNDB06 TS: SYSSEQ    
BRF tablespace DB: DSNDB06 TS: SYSSEQ2   
BRF tablespace DB: DSNDB06 TS: SYSSTATS  
BRF tablespace DB: DSNDB06 TS: SYSTARG   
BRF tablespace DB: DSNDB06 TS: SYSUSER   
BRF tablespace DB: DSNDB06 TS: SYSXML    
CDB table LUMODES has row - LUNAME DKLTEST MODENAME MODTEST.
CDB table LUNAMES has row - LUNAME DKLTEST SYSMODENAME MODTEST.
CDB table LUNAMES has row - LUNAME ROYTEST SYSMODENAME -none-.
CDB table MODESELECT has row - LUNAME DKLTEST AUTHID DKLTEST_AUTH_ID PLANNAME DKLTEST.

Note the WRKxxxx tablespaces…

Start to plan today!

Using our MigrationReadiness HealthCheck for Db2 z/OS freeware you can start to divvy up and plan all of the work that will be coming down the vNext road towards you. Start now and you still have over two years to get it all done and actioned. Start in two years and you will never make it – The choice is yours!

TTFN,

Roy Boxwell