Use Base 36 to squeeze the character representation of large numbers into a small space without using binary.

Almost every developer has run into this scenario. The boss announces you're integrating your legacy ERP software with an external system. You've been tasked to find a place to store a transaction ID from the external system in your legacy INVOICE table. Neither changing the existing table definition nor creating a new table is an option. Reviewing the INVOICE table, you rejoice to find an unused CHAR(6) user-defined field. This is where you'll store the transaction ID. Thereafter, your countenance falls when you find that the transaction ID requires eight digits. Everyone knows this is a lost cause because you can't cram eight digits into CHAR(6). Or can you?

One possible solution to this problem is converting the transaction ID to a binary integer format (such as an SQL BIGINT or RPG 20I 0) and slamming the result (truncating the first two bytes) into the CHAR(6) column. The only drawback to this solution is that the host application may cause a problem when displaying the binary data on the green-screen or when giving the data to a web site for display. Therefore keeping the number in text format is important.

Fortunately, there are other solutions that don't require binary conversion.

One such resolution would be to convert the eight-digit decimal number to hex. Whereas decimal is a base 10 numbering system (with 10 digits 0-9), hex is Base16 (with 10 digits and six letters, A-F). When storing a numeric value in a character column with hex, each position in the CHAR(6) column can hold 16 values instead of 10. Storing a decimal number in a CHAR(6) column will allow 1,000,000 (10^6) combinations from 0 through 999,999. Storing the number as hex will allow 16,777,216 combinations ranging from 0 through 16,777,215—another six million values! The largest six-character number represented with hex is FFFFFF. Storing an integer as a hex value isn't as efficient as storing as binary, but it uses characters that are safe to display. Even though the largest possible number we can accept in hex is 16.7 million, perhaps this isn't big enough to hold the possible values received over the life of the application.

Another option, which offers yet more compaction, is to convert the numeric transaction ID value to Base 36 (also known as hexatridecimal or hexatrigesimal). Using the Base 36 numbering system allows each position in the CHAR(6) column to hold 36 values (with 10 digits and 26 English alphabet letters). In total, storing a number as Base 36 will allow a storage range of 0 through 2,176,782,335 (36^6). This method gives about half of the storage values of an unsigned 32-bit integer. Not a bad tradeoff. Even a CHAR(3) column can store 36^3 (46,656) values when using Base 36.

The table below shows various decimal numbers represented in hex and hexatridecimal.

The attached RPG service program BASE36R contains two subprocedures (CvtToBase36 and CvtFromBase36) that convert between big integers and Base 36 and vice versa.

The RPG program should be accessible to users on V5R4 or higher (it can be modified for earlier versions). The logic to convert a number to Base 36 is basic; just continue to divide a number by 36 and assign the remainder as the appropriate character (0-9 or A-Z). The quotient is saved for the next iteration of the same logic until the quotient is zero. I used the PHP implementation shown on the Wikipedia page as the basis for the RPG code.

The reason for using characters A-Z is to make sure everything stored is readable in character-based storage; otherwise, we could just convert to binary. Base 36 is only one of many such systems that can be implemented.

Further, these conversion routines can be made available to DB2 for i-enabled applications by defining external user-defined function wrappers on the RPG code as shown here (IBM i 6.1 users and prior should remove "OR REPLACE" option):

CREATE OR REPLACE FUNCTION zzz.CvtToBase36

(Number BIGINT)

RETURNS VARCHAR(16) CCSID 37

LANGUAGE RPGLE

EXTERNAL NAME 'zzz/BASE36R(CVTTOBASE36)'

DETERMINISTIC

NOT FENCED

PARAMETER STYLE GENERAL

NO SQL;

CREATE OR REPLACE FUNCTION zzz.CvtFromBase36

(Base36Value VARCHAR(16) CCSID 37)

RETURNS BIGINT

LANGUAGE RPGLE

EXTERNAL NAME 'zzz/BASE36R(CVTFROMBASE36)'

DETERMINISTIC

NOT FENCED

PARAMETER STYLE GENERAL

NO SQL;

The function is easy to use. The following query returns the scalar result 1ZCX4D6M69:

SELECT Base36Value

FROM (VALUES(CvtToBase36(201311271224001))) X(Base36Value);

Uses for Base 36

I recently had a coworker use this technique. Our software is tasked with giving an export to a legacy system that can't be upgraded. The legacy system's job is to manipulate the data and send it back. A numeric transaction ID is slapped into a CHAR(6) column and remains untouched by the external system so that our software can keep track of each piece of information when it comes back. Once the transaction ID had reached one million, the link to the external system broke because the export file couldn't be changed to hold a CHAR(7) transaction ID.

The implemented fix was to convert our software's transaction ID to Base36 and continue to put it in the export file as CHAR(6). The legacy system could then process the file and send it back. Our software would read the Base 36 transaction ID, convert it back to numeric, and continue processing as usual. Using Base 36, we won't have to worry about the problem again until the transaction ID reaches 2 billion!

Other uses for Base 36 involve shrinking long numbers for readability. Say a serial number of 201311271224001 will be placed on a label that a user may need to read to a customer support rep someday. If this code is converted to Base 36, it's potentially easier to read: 1ZCX4D6M69. Further, the Base 36 representation can fit on a smaller label and provides the luxury of using a larger font. The Wikipedia entry on Base36 gives several more instances of how it's used in the industry.

A Few Notes

• Do not confuse changing the representation of a number using Base 36 with Base64 encoding. The two are not related! Base64 is used to encode binary information using only 64 standard ASCII characters, so it actually makes the encoded data larger than the original.
• Left-justified Base 36-encoded numbers do not sort, especially in EBCDIC! Convert the Base 36 to decimal/integer to sort correctly.
• When dealing with negative numbers, the smallest number the RPG program can handle is -9223372036854775807 instead of the expected -9223372036854775808. This is because of how the program works with positive numbers when doing the calculations.

In summary, Base36 allows for the compacting of the character representation of numeric data without resorting to a binary conversion. Base36 can help with data exchange and readability issues to name a few uses.