RevMedia

Users of other systems coming to AREV for the first time cannot help but notice that as a consequence of the lack of "typing" data, is that all data is stored as ASCII strings with no specialised storage for integers or real numbers. This is not a particularly efficient way of coping with integers, one byte could be used to represent a number between 0 and 255 rather than just 0 and 9 as at present.

Normally this restriction is not a limitation, but in the case of relational indexes it can severely limit our system. As a rough rule of thumb, assuming a five digit key, only 8-10,000 record keys can be stored in a relational index. In addition, one BTREE node (being limited in size to around 1K) can only store 150-200 such keys, meaning that every 150-200 keys returned from a BTREE.EXTRACT operation requires an additional disk i/o.

It would therefore be a good idea were an alternative base to be used in place of base 10 for integer keys. If a higher base, such as base 210, were used, two bytes could contain up to 44099 rather than 99. This sort of compaction more than doubles the amount of records possible to maintain in a relational index, and does the same for BTREE nodes.

The choice of base within AREV is limited. We need to express the number by storing ASCII characters. If we used Base 256,

The system, however uses characters above 246 as delimiters, so characters above 246 could not be used as they would be treated as delimiters. It might therefore seem reasonable to use Base 246 so these problems are not encountered. However the use of Base 246 is again precluded, because as has been shown in REVMEDIA passim, low ASCII characters can create problems with keys. A base starting at CHAR(33) (so as to avoid spaces in keys) and finishing below CHAR(247) is therefore desirable - for personal reasons, the author chooses to use Base 210.

The best way to implement the use of another Base within AREV is as a User Defined Conversion. On ICONV the routine must take an ASCII integer and process it to create the data in the alternative base. On OCONV the routine must take the alternative base data and convert it back to a Base 10 integer.

The code presented below achieves this functionality. If defaults to Base 210 but any base may be used by using the option branch label on the ICONV/OCONV call. The routine must be entered, compiled and and catalogued. Then to convert 2500 to Base 210 one would use INTERN = ICONV(2500,"[BASE]"). To convert to Base 150 one would use INTERN = ICONV(2500,"[BASE,150]". TO OCONV reverse the exercise, eg EXTERN = OCONV(INTERN,"[BASE]") and EXTERN = OCONV(INTERN,"[BASE,150]") respectively.

Note that this form of Base conversion is not what a mathematician would term a Base conversion but it achieves our required objectives.