#128 Error with Virtual Object encoding

Core Model (79)


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.

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

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


  • Jerry Goodnough

    Jerry Goodnough - 2004-05-05

    Logged In: YES

    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

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


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks