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).
Some Mumps system do not like character 255 in the
subscript. For example DSM has trouble with this when
performing a $Query operation.
1) Avoid those virtual object numbers that generate the
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
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
Log in to post a comment.