Automic Workload Automation

Hello,

Here is a little script that will allow you to retrieve which RunID generated a given report file, or which report file you should look for for a given RunID.

:READ &CHOICE#,"'Report to RunID','RunID to Report'",'Select type of conversion',

:SWITCH &CHOICE#
!Convert a report name to a RunID
:  CASE 'REPORT TO RUNID'
:      READ &REPORT_NAME#,,,,"M"
:      SET &ALPHA# = MID ("&REPORT_NAME#", 2, 7)
:      SET &RUNID# = ALPHA2RUNNR ("&ALPHA#")
:      SET &RUNID# = FORMAT(&RUNID#)
:      PRINT Report : &REPORT_NAME# = RunID &RUNID#

!Convert a RunID to a report name
:CASE 'RUNID TO REPORT'
:      READ &RUNID#,,,,"M"
:      SET &ALPHA# = RUNNR2ALPHA(&RUNID#)
:      SET &REPORT_NAME#=STR_CAT("O",&ALPHA#)
:      SET &REPORT_NAME#=STR_CAT(&REPORT_NAME#,".txt")
:      PRINT RunID : &RUNID# = &REPORT_NAME#
: ENDSWITCH

Could you share the algorithm behind ALPHA2RUNNR and RUNNR2ALPHA?

Hi Michael,

We cannot share this kind of information, as it has to do with the application source code.

Thanks for your understanding,
Antoine

As Carsten discovered, RUNNR2ALPHA returns a result even for nonexistent run IDs. It seems to be is a simple one-to-one mapping. That is, for every numeric run ID, there is exactly one unique alphabetic job ID, and vice versa.

Michael,
We appreciate your interest and your engagement to understand fully our software, but please agree with us, that this kind of information, since it is part of the sourcecode, should remain on developers side.

Please let us know the usecase for knowing the mechanism behind it, so we can try to find an alternative for archiving it.

Thank you!

Mostly it’s pure curiosity. But I suppose it would be useful for integrating the AE with external tools. The example that brought this topic to my attention was archiving from several agents job logs that were too large to be transferred to the AE DB.

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 forRUNNR2ALPHAstates 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 forALPHA2RUNNRstates 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.

In a discussion about OH_Idnr numbers, Josef_Scharl_103 confirmed that AH_Idnr numbers are limited to 31 bits.

...I guess  it’s similar to the run idnrs (AH_IDNR). They will turn around when the limit (0x7FFFFFFF) is reached.