Re: The case of outnumbered numerator

Its not clear to me what volumes he is anticipating. If he is at 899,999 now in a file that is 10 years old then he doesn't need base36. That is way overkill. On the other hand, if volumes are such that he is needing base36 then my guess is that he might as well bite the bullet and expand the field, cuz base36 is just a band aid for him.

Properly evaluating anticipated volume is a part of the decision process, much more so than sticking in a base36 solution that will be nothing but a confusing maintenance and design headache going forward.

On 6/17/2015 12:13 PM, John Yeung wrote:

On Wed, Jun 17, 2015 at 12:40 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

My first thought is to do it the other way round. Put the letter to the
front, not to the rear. A99999,B00000, B00001... etc.

You're missing a couple of key points though. First, it's not like
he's really looking to make the first character a "digit" and the
subsequent characters "letters". He wants to make *every single
character* able to take any of 36 possible values. For example, at
some point, the field in question will have the value '9AA3XY'. He
wants the next one to be '9AA3XZ', and then the one after that to be
'9AA3X0'.

The second crucial point is: He wants to keep the natural EBCDIC sort
order. (Or collating sequence, to use IBM's terminology.) In EBCDIC,
the letters come before the digits. So the value 'Z99999' actually
comes *before* '000000', or indeed, anything starting with zero. The
next value after 'Z99999' would be '0AAAAA'.

John Y.