r-code version numbers - Forum - OpenEdge General - Progress Community
 Forum

r-code version numbers

This question is answered

According to the kbase: https://knowledgebase.progress.com/articles/Article/P113957/ there  is no algorithm to map version the r-code numbers reported by error 2888 to human meaningful version numbers.

Ok, fine.

Does anyone happen to have collated a table of some known mappings between those version numbers and recognizable Progress version numbers?

At the moment I am wondering about:

Invalid version 17391, (expected 1100)...

(I obviously don't have access to the machine in question right now...)

--
Tom Bascom
tom@wss.com

Verified Answer
  • Here is list going back to 9.x.

    900; // has appserver code

    908; // 9.0b without acs segments

    909;  // uses 4 acs segments

    1005; // 10.0a

    1006; // 10.1b uses longchar

    1007; // 10.1a with new datasets/64bit

    1008; // 10.1b with 64bit

    1009; // support for stream handles

    1100; // oe version 11 reorg.

    1101; // oe 11.6 changes

    17391 isn't a real version. Might not even be r-code.

  • 17391 - 16384 (2^14) = 1007

    Anything below 1000 is v9 or earlier. Anything between 1000 to 1099 is version 10 (and I think 1008 is the last value, for 10.2B). Anything above 1100 is version 11.

    So they execute 10.2B with 64 bits rcode, on a v11 AVM.

All Replies
  • Here is list going back to 9.x.

    900; // has appserver code

    908; // 9.0b without acs segments

    909;  // uses 4 acs segments

    1005; // 10.0a

    1006; // 10.1b uses longchar

    1007; // 10.1a with new datasets/64bit

    1008; // 10.1b with 64bit

    1009; // support for stream handles

    1100; // oe version 11 reorg.

    1101; // oe 11.6 changes

    17391 isn't a real version. Might not even be r-code.

  • 17391 - 16384 (2^14) = 1007

    Anything below 1000 is v9 or earlier. Anything between 1000 to 1099 is version 10 (and I think 1008 is the last value, for 10.2B). Anything above 1100 is version 11.

    So they execute 10.2B with 64 bits rcode, on a v11 AVM.

  • Great answers!  Maybe someone could add it to the kbase above?

    --
    Tom Bascom
    tom@wss.com

  • Hi Tom,

    One of our KDEs (Knowledge Domain Experts) will update the article with this information.

    Thank you.

  • Matt, the sequence looks funny.  Should:

     1007; // 10.1a with new datasets/64bit

     1008; // 10.1b with 64bit

    be 10. *2*?

    --
    Tom Bascom
    tom@wss.com

  • This is just a copy/paste out of some PDSOE code.

    I left the comments as-is from the code I pasted.  Probably someone's phat phinger from years ago (mine :( ).

    mattB

  • Sounds like it may have been unintended but the compiler versions in the r-code were different in v10 for 32-bit vs. 64-bit r-code.  As Gilles said, 17391 is a 64-bit .r.  

    With a hex editor or xxd you can see the two-byte compiler version in a .r, starting at byte 15 (little-endian in this case).

    10.2B08:

    0000000: 09d3 ce56 2729 3e5b 2000 0000 38ff ef43  ...V')>[ ...8..C

    11.6.3:

    0000000: 09d3 ce56 6929 3e5b 0000 0000 0080 4c04  ...Vi)>[......L.

    0x43ef = 17391

    0x044c = 1100

  • Huh?  The difference is that it is 10 vs 11, not that it is 32-bit vs 64-bit.  The value should never be different based on the bit-ness.  As Matt already said, that 17391 value looks incorrect.  But no matter because you need to recompile between major versions, as has already been said.  So not sure why the conversation is continuing.  Is there another question?

  • In my experience, 32-bit 10.2B r-code was 1005 (0x03ed).  That's what I get from a 32-bit compiler in Windows, 10.2B08.  

    There used to be an r-code tab under Properties when you right-clicked on a .r.  I don't get that anymore, maybe because other releases have been installed on my machine since.  That tab also showed the compiler version.

  • > Huh?  The difference is that it is 10 vs 11, not that it is 32-bit vs 64-bit.

    I wasn't saying that 32 vs. 64 was the reason for the invalid version error.  

    Just pointing out that there was more than one version number for a given release, based on the bit-ness of the compiler.  It can be helpful to know that when working in mixed-platform environments.

  • The 17391  is correct.  high bit is set on the short to indicate 32 vs 64 r-code.  For PDSOE this was never a concern due to the way we read the short, it masked off the high bit.  Also, PDSOE never reads the executable sections so it never really cared about the difference.

    You won't see high bit set any more because in 11+ because there is no longer any 32 and 64 bit r-code...it is all the same format now.