DB2 11 for z/OS Extended RBA/LRSN Migration - by David Simpson

By David Simpson posted Aug 20, 2015 08:54 AM


Many companies are planning a migration to DB2 11 for z/OS because of the support for expanding the RBA and LRSN.  Planning for the expansion is a post-migration task that will require some thought.  Let’s take a look at the process.

Logging in DB2 for z/OS

DB2 addresses its log with a Relative Byte Address (RBA) that has been 6 bytes long since the beginning.  This value always increases and does not automatically wrap around when the highest value is reached.  This allows for a maximum of 256 Terabytes of log to be accumulated over the life of a subsystem before intervention is needed.  There is a procedure to “reset” the value when it gets close to the end which is time consuming and intrusive.

The Log Record Sequence Number (LRSN) is also a 6 byte number that coordinates log sequencing among different subsystems in a data sharing group that will each have their own logs and therefore different values for RBA.  It is derived from the time of day clock.  It hit its highest possible value in the year 2042 unless it has been advanced due to the way data sharing was implemented.

DB2 11 in NFM allows for a 10 byte RBA and LRSN which should solve the problem of “running out” for the foreseeable future.  After migration to DB2 11 NFM the RBA and LRSN values will still be 6 bytes.  There are several steps that administrators need to take to fully implement the “Extended” (larger) RBA and LRSN. 

The Extra Bytes

For the RBA on a single DB2 subsystem or member all the new bytes are placed at the beginning of the address.  For LRSN the extra bytes are split.  One byte is added to the beginning and the other 3 are added to the end. This will solve 2 problems related to LRSN.  The extra byte on the left side allows for approximately 30,000 years of addressing.  The extra precision on the right will solve a common performance problem in data sharing when a DB2 system needs a unique value for LRSN (sometimes referred to as the “LRSN Spin” problem).  The extra precision on LRSN will eliminate the need to wait for unique values.



DB2 11 will display messages using the “extended” RBA / LRSN regardless of whether or not the conversion is complete.  This is true even in Conversion Mode (CM). The example shown here is from a DB2 11 CM system that is still functioning with 6 byte RBA / LRSN values.  The messages in DB2 will always convert to display the larger value.

RBA Messages

Conversion Process

There are 3 parts to the migration to “extended” RBA / LRSN values. DB2 must be in NFM in order to begin this process.  These steps may be accomplished in any order.

  • First the BSDS datasets must be converted to the larger format. While not required, it is advisable to run this step first for performance reasons.  The installation panels tailor job DSNTIJCB to accomplish this task.  The DB2 subsystem must be down in order to run this job.
  • Second, the catalog and directory must be converted via REORG utilities. This may be done before the BSDS is converted or after some application tablespaces but it is a good idea to accomplish these tasks in order.  Job DSNTIJCV runs online reorgs of the catalog and directory objects with the necessary control cards to convert these objects to the extended format.
  • Because RBAs are embedded in every pageset, every application tablespace and index must eventually be converted by running reorgs with the control card RBALRSN_CONVERSION EXTENDED included. The zParm called UTILITY_OBJECT_CONVERSION may also be used to allow this conversion to happen by default when objects are reorganized.

Converting application tablespaces and indexes may be done with LOAD REPLACE, REORG or REBUILD INDEX.  This is an example of using REORG to explicitly convert a tablespace and its associated indexes to the expanded format.  The output indicates which objects were converted.

Convert with Reorg

Subsystem Parameters

Consideration should be given to the values for two subsystem parameters after you reach DB2 11 NFM.  OBJECT_CREATE_FORMAT will control the format for newly created objects.  After the BSDS is converted it is probably a good idea to set this to a value of EXTENDED. 

UTILITY_OBJECT_CONVERSION has four possible values and will control the behavior of REORG, LOAD REPLACE and REBUILD INDEX when RBALRSN_CONVERSION is not specified.

  • BASIC – convert extended objects back to the basic format.
  • EXTENDED – convert basic objects to the extended format.
  • NOBASIC – always convert basic objects to the extended format and do not allow utility control card overrides.
  • NONE – no automatic conversion in either direction.

Except for the case of NOBASIC, the utility control card will override the value for this subsystem parameter.


You must be DB2 11 NFM to begin this process.  The catalog is not yet ready for bigger values while you are in DB2 11 CM. 

There may be a small amount of performance degradation if the boot strap is still in BASIC format but objects are EXTENDED.  This is due to the backwards conversion needed to create log records in the smaller format.

If you are getting close to the 6 byte “high values” then converting the boot strap may actually accelerate the process.  After the boot strap is converted DB2 begins cutting log records with the extended RBA format.  This actually makes the log records longer resulting in more log consumed for the same workload and thus more rapid consumption of the available RBA values.  This is a significant consideration if you are under the gun to get the process complete before running out of the 6 byte values.

David Simpson
Themis Education