SOLVED: Issue with Version inspector & new Adobe DC versioning

Ideas
1

APAR IV72372 - the fix should be in the 9.3 client.
Service request number: 66097,7TD,000

Adobe’s new DC versioning scheme causes errors with the version inspector:

Q: "15.006.20456.110321" as version
E: Singular expression refers to nonexistent object.

If the last version number was 1 number shorter, it would work:

Q: "15.006.20456.11032" as version
A: 15.6.20456.11032
T: 0.040 ms
I: singular version

This will require some manual workarounds in relevance to handle unless the version inspector could be expanded to handle this case. This will also require rewriting of many analyses that we have currently.

It seems like this is Adobe’s new way of versioning going forward, so this may affect all adobe products.

This issue also may affect many of the analyses that are provided by IBM already.

Workaround:

This is not perfect because it will not report the actual version, but rather a version that can be used with the version inspector without issue. This should be acceptable because the issue with the adobe version numbers is with the last set of numbers, which are the least likely to matter for long periods of time. ( If an earlier set of numbers in a version increments, then the sets after it do not matter as far as comparisons go )

(it as version | (it as version) of preceding text of last "." of it | (it as version) of preceding text of last "." of preceding text of last "." of it) of ( (preceding text of last "." of it) & "." & (it as string) of (it mod 65536) of (it as integer) of following text of last "." of it) of (it as string as trimmed string) of "15.006.20456.65535.0.0"

Reference:
http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/basics.html#versioning-strategy

2

Actually it looks to me like this is rooted in using a xx32xx 16-bit signed integer for each component of the Version type, which overflows at 32,768:

Q: “32767” as version
A: 32767
T: 0.018 ms
I: singular version

Q: “32768” as version
E: Singular expression refers to nonexistent object.

1 Like
3

That is very interesting. I assumed length of that part of the string was the issue, not the integer it represented.

4

You’re absolutely right on 16-bit, edited above. Not enough coffee today.

1 Like
5

FWIW, I tried this on QnA 9.2.4.2 on a Mac and it seems to work as expected:

Q: "15.006.20456.110321" as version
A: 15.006.20456.110321
T: 24273

On Windows Fixlet Debugger 9.2.2.21 I get:

Q: "12345" as version
A: 12345
T: 0.039 ms

Q: "123456" as version
E: Singular expression refers to nonexistent object.
1 Like
6

Could you file a PMR for this. It should be moderately easy to fix but of course it won’t help the existing agents :frowning:

Mac and UNIX will work with this due to the way they have to handle non numeric versions

1 Like
7

Just opened the PMR for this.

Service request number: 66097,7TD,000

8

Well this is interesting:

Q: "32767.65535.65535.65535" as version
A: 32767.65535.65535.65535
T: 0.034 ms
I: singular version

This appears to be the maximum version allowed by the inspector on windows. If I increment any of the sets of numbers by 1, then it fails.

9

Windows internally has a 16bit.16bit.32bit number that it keeps for versions.

1 Like
10

I am told that the fix will be in the 9.3 client and the PMR is resolved. Thanks.

11

I think the version number of the client they told you is wrong but yes I have already made the fix and it should be in the next patch (whatever number that is)

1 Like