Bookmark and Share

Recent Posts

Converting from 6- to 10-byte RBA/LRSN

January 9, 2018

Db2 11 introduced an option to convert the log relative byte address (RBA) and data sharing log record sequence number (LRSN) from the basic 6-byte format to the extended 10-byte format. Timm Zimmermann of the IBM Db2 for z/OS development "swat team" has a great presentation that goes into the details on the different formats. More importantly, Timm lays out the dwindling time that customers have left to convert their old 6-byte addresses and numbers to the soon-to-be standard 10-byte format.

The presentation covers the process of converting the boot-strap-dataset (BSDS), Db2 catalog and user objects. Technically speaking, as long as you convert everything at once, the order in which you do so shouldn't be an issue. That said, there are dos and don'ts with this. Let's start this don't: What you don't want to do is convert only the BSDS and put off the rest for weeks or months. In this case, you would likely end up having to reset the RBA to 0, and that's something to avoid at all costs.

Once you convert the BSDS, you lose capability to automatically monitor how soon you'll reach the hard limit of the basic 6-byte RBA/LRSN. This is because Db2 is now monitoring the new limit based on the extended 10-byte RBA/LRSN. And while the 6-byte RBA in the catalog or user objects are reaching the limit, the 10-byte format BSDS is not. So you won't receive any notification (namely, the DSNJ032I warning message) before hitting the hard limit on an unconverted object.

To avoid this situation, I recommend that your conversion process starts with the catalog first, then user objects, and then BSDS. In my experience, this is what most customers do. This approach ensures that Db2 will continue to monitor and display the DSNJ032I message should you near the hard limit during the conversion process.

If you've already going through this, please share your experience in comments.

Posted January 9, 2018| Permalink

comments powered by Disqus