I ran a few tests to try to better understand the algorithms behind
ALPHA2RUNNR
and
RUNNR2ALPHA
.
Code:
:SET &MIN_RUN_ID# = 0
:SET &MAX_RUN_ID# = 50
:SET &RUN_ID# = &MIN_RUN_ID#
:WHILE &RUN_ID# <= &MAX_RUN_ID#
: SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
: PRINT "Original Run ID : &RUN_ID_FMT#"
: SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
: PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
: SET &RUN_ID# = &RUN_ID# + 1
:ENDWHILE
Result:
Original Run ID : 0000000000
RUNNR2ALPHA Job ID : AAAAAAA
Original Run ID : 0000000001
RUNNR2ALPHA Job ID : AAAAAAB
Original Run ID : 0000000002
RUNNR2ALPHA Job ID : AAAAAAC
Original Run ID : 0000000003
RUNNR2ALPHA Job ID : AAAAAAD
...
Original Run ID : 0000000024
RUNNR2ALPHA Job ID : AAAAAAY
Original Run ID : 0000000025
RUNNR2ALPHA Job ID : AAAAAAZ
Original Run ID : 0000000026
RUNNR2ALPHA Job ID : AAAAABA
Original Run ID : 0000000027
RUNNR2ALPHA Job ID : AAAAABB
Original Run ID : 0000000028
RUNNR2ALPHA Job ID : AAAAABC
...
So far, it seems like a simple conversion from base 10 to base 26. What if we go all the way to
ZZZZZZZ?
Code:
:SET &JOB_ID# = "ZZZZZZZ"
:PRINT "Original Job ID : &JOB_ID#"
:SET &RUN_ID# = ALPHA2RUNNR(&JOB_ID#)
:SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
:PRINT "ALPHA2RUNNR Run ID : &RUN_ID_FMT#"
:SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
:PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
:PRINT
...
Result:
Original Job ID : ZZZZZZZ
ALPHA2RUNNR Run ID : 0558124417
RUNNR2ALPHA Job ID : BUZIXVT
Original Job ID : ZZZZZZY
ALPHA2RUNNR Run ID : 0558124418
RUNNR2ALPHA Job ID : BUZIXVU
Original Job ID : ZZZZZZX
ALPHA2RUNNR Run ID : 0558124419
RUNNR2ALPHA Job ID : BUZIXVV
Original Job ID : ZZZZZZW
ALPHA2RUNNR Run ID : 0558124420
RUNNR2ALPHA Job ID : BUZIXVW
Counting down from job ID
ZZZZZZZ, the corresponding run IDs are actually
increasing instead of decreasing. And if we take these run IDs and generate job IDs from them, we get different strings than the originals. So at least in this range, it’s not a simple base 10 to base 26 conversion after all.
Next, I tried to find the maximum run ID that could be converted into a job ID. In our production system, run IDs recently grew from 8 to 9 digits in length. First, I looked at the boundary between 9 and 10 digit numbers.
Code:
:SET &MIN_RUN_ID# = 999999950
:SET &MAX_RUN_ID# = 1000000050
:SET &RUN_ID# = &MIN_RUN_ID#
:WHILE &RUN_ID# <= &MAX_RUN_ID#
: SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
: PRINT "Original Run ID : &RUN_ID_FMT#"
: SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
: PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
: SET &RUN_ID# = &RUN_ID# + 1
: PRINT
:ENDWHILE
Result:
Original Run ID : 0999999998
RUNNR2ALPHA Job ID : DGEHTYK
Original Run ID : 0999999999
RUNNR2ALPHA Job ID : DGEHTYL
Original Run ID : 1000000000
RUNNR2ALPHA Job ID : DGEHTYM
Original Run ID : 1000000001
RUNNR2ALPHA Job ID : DGEHTYN
Original Run ID : 1000000002
RUNNR2ALPHA Job ID : DGEHTYO
Nothing unusual there. Next, I looked at the boundary between 10 and 11 digit decimal numbers.
Result:
Original Run ID : 9999999950
RUNNR2ALPHA Job ID : GYTISYY
...
Original Run ID : 10000000050
RUNNR2ALPHA Job ID : GYTISYY
At least in this range, all the results were the same:
GYTISYY. Next, I looked a the neighboring range of job IDs.
Code:
:SET &JOB_ID# = "GYTISYW"
:PRINT "Original Job ID : &JOB_ID#"
:SET &RUN_ID# = ALPHA2RUNNR(&JOB_ID#)
:SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
:PRINT "ALPHA2RUNNR Run ID : &RUN_ID_FMT#"
:SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
:PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
:PRINT
:SET &JOB_ID# = "GYTISYX"
:PRINT "Original Job ID : &JOB_ID#"
:SET &RUN_ID# = ALPHA2RUNNR(&JOB_ID#)
:SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
:PRINT "ALPHA2RUNNR Run ID : &RUN_ID_FMT#"
:SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
:PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
:PRINT
:SET &JOB_ID# = "GYTISYY"
:PRINT "Original Job ID : &JOB_ID#"
:SET &RUN_ID# = ALPHA2RUNNR(&JOB_ID#)
:SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
:PRINT "ALPHA2RUNNR Run ID : &RUN_ID_FMT#"
:SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
:PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
:PRINT
:SET &JOB_ID# = "GYTISYZ"
:PRINT "Original Job ID : &JOB_ID#"
:SET &RUN_ID# = ALPHA2RUNNR(&JOB_ID#)
:SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
:PRINT "ALPHA2RUNNR Run ID : &RUN_ID_FMT#"
:SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
:PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
:PRINT
:SET &JOB_ID# = "GYTISZA"
:PRINT "Original Job ID : &JOB_ID#"
:SET &RUN_ID# = ALPHA2RUNNR(&JOB_ID#)
:SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
:PRINT "ALPHA2RUNNR Run ID : &RUN_ID_FMT#"
:SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
:PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
:PRINT
Result:
Original Job ID : GYTISYW
ALPHA2RUNNR Run ID : 2147483646
RUNNR2ALPHA Job ID : GYTISYW
Original Job ID : GYTISYX
ALPHA2RUNNR Run ID : 2147483647
RUNNR2ALPHA Job ID : GYTISYX
Original Job ID : GYTISYY
ALPHA2RUNNR Run ID : 6744071562067968
RUNNR2ALPHA Job ID : GYTISYY
Original Job ID : GYTISYZ
ALPHA2RUNNR Run ID : 2147483647
RUNNR2ALPHA Job ID : GYTISYX
Original Job ID : GYTISZA
ALPHA2RUNNR Run ID : 2147483646
RUNNR2ALPHA Job ID : GYTISYW
Something unusual happens at
GYTISYY. The run IDs overflow and then begin counting down again, instead of up. If we take a close look at the range of run IDs around, 2147483647, we see
Code:
:SET &MIN_RUN_ID# = 2147483645
:SET &MAX_RUN_ID# = 2147483650
:SET &RUN_ID# = &MIN_RUN_ID#
:WHILE &RUN_ID# <= &MAX_RUN_ID#
: SET &RUN_ID_FMT# = FORMAT(&RUN_ID#,"0000000000")
: PRINT "Original Run ID : &RUN_ID_FMT#"
: SET &JOB_ID_ALPHA# = RUNNR2ALPHA(&RUN_ID#)
: PRINT "RUNNR2ALPHA Job ID : &JOB_ID_ALPHA#"
: PRINT
: SET &RUN_ID# = &RUN_ID# + 1
:ENDWHILE
Result:
Original Run ID : 2147483645
RUNNR2ALPHA Job ID : GYTISYV
Original Run ID : 2147483646
RUNNR2ALPHA Job ID : GYTISYW
Original Run ID : 2147483647
RUNNR2ALPHA Job ID : GYTISYX
Original Run ID : 2147483648
RUNNR2ALPHA Job ID : GYTISYY
Original Run ID : 2147483649
RUNNR2ALPHA Job ID : GYTISYY
Original Run ID : 2147483650
RUNNR2ALPHA Job ID : GYTISYY
2147483647 is 1111111111111111111111111111111 in base 2, so my guess is
that internally (at least for the purpose of these functions), run IDs
are stored as 31 bit numbers. Whether this also corresponds to the
highest possible run ID in the AE, I do not know. I was not able to find
any mention of this in the documentation; however this number is
mentioned in afew other places.
The documentation forRUNNR2ALPHA
states that it takes a 10 digit decimal run ID as its argument.
2147483647 is thehighest decimal run ID for which the command returns a meaningful result.
The documentation forALPHA2RUNNR
states that it takes a 7 character alphabetic job ID as its argument.
GYTISYX is thehighest alphabetic job ID for which the command returns a meaningful result.