#128 Error with Virtual Object encoding

[Jerry Goodnough]

Background:

Virtual Objects encode thier pointers using a binary set
to the virtual class number. "V" class pointers use two
characters of the pointer for this value. The Version 4.0
encodding does not allow a character with a value of
zero (0), since this results in a subscript error on some
M systems. The remainder of the characters from 1 to
255 are used to record the class id. The actual number
is derived by treats the character pair as a high byte
(minus 1) followed by the low byte (minus 1).

Issue:

Some Mumps system do not like character 255 in the
subscript. For example DSM has trouble with this when
performing a $Query operation.

Work arrounds:

1) Avoid those virtual object numbers that generate the
$C(255) character.

2) Allocate a new Id for any conflicting class, and
maintain the old linkage in the Virtual mapping table.
Reset any old virtual pointers that need it to the new
value.

Classes effected:

Class that have a virtual Id that is evenly divisible by
254 will exhibit this problem.

EsiObjects Test Code: If T%Id#254=0 ;This is class is
effected.

[Jerry Goodnough]

Logged In: YES
user_id=41717

Math error in the detection code... It should be:

If T%Id#255=254 .....

[Terry L. Wiechmann]

Patch for Bug 947496.

[Terry L. Wiechmann]

Logged In: YES
user_id=84471

The attached .opf solves the problem of using ID# 255. Use
the Tools|Generic Import command to import the fix.