r-code version numbers

Posted by ChUIMonster on 05-Jul-2018 08:01

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...)

Posted by Matt Baker on 05-Jul-2018 08:11

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.

Posted by Riverside Software on 05-Jul-2018 08:13

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

Posted by Matt Baker on 05-Jul-2018 08:11

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.

Posted by Riverside Software on 05-Jul-2018 08:13

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.

Posted by ChUIMonster on 05-Jul-2018 08:17

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

Posted by Carol A. Osborne on 05-Jul-2018 08:24

Hi Tom,

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

Thank you.

Posted by ChUIMonster on 05-Jul-2018 08:26

Matt, the sequence looks funny.  Should:

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

 1008; // 10.1b with 64bit

be 10. *2*?

Posted by Matt Baker on 05-Jul-2018 08:35

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

Posted by Rob Fitzpatrick on 05-Jul-2018 09:26

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

Posted by Laura Stern on 05-Jul-2018 09:33

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?

Posted by Rob Fitzpatrick on 05-Jul-2018 09:33

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.

Posted by Rob Fitzpatrick on 05-Jul-2018 09:37

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

Posted by Matt Baker on 05-Jul-2018 09:46

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.

This thread is closed