#24 Numeric subscript errors in GT.CM (OMI)

Edwin Clubb

I am using an OMI client running on DTM 6.6 and while I can connect to the gtcm_server and
perform all OMI operations (using extensions 1 & 3), I am experiencing problems with global
references that contain numeric subscripts which are either floating point values with more than 12
digits to the right of the decimal point, or are integers of more than 17 digits. When I examine the
logs on the OMI client, it appears to be sending the correct values to the server.

In the case of floating point subscripts, the OMI client can set the value and reference the value,
but subsequent $data operations return a false "true" when the non-existant reference rounds up
to an existing one. Here is some sample output from the DTM OMI client that demonstrates the

>w $zv
Open M [DTM] for MS-DOS/6.6/18AUG98 NETWORK WS 32-BIT/Build 05

>k ^zzz

>s ^zzz(12.33333333333333)="test"

>w $d(^zzz(12.33333333333333))
>w $d(^zzz(12.333333333333331))
>w $d(^zzz(12.333333333333334))
>w $d(^zzz(12.333333333333335))
>w $d(^zzz(12.33333333333333123))
>s ^zzz(1234.567890123456)="test2"

>w $d(^zzz(1234.567890123456))
>w $d(^zzz(1234.5678901234561))
>w $d(^zzz(1234.5678901234564))
>w $d(^zzz(1234.5678901234565))
>w $d(^zzz(1234.56789012345612345))
>s ^zzz(123456789012345678)="test3"

>w $d(^zzz(123456789012345678))
>w $d(^zzz(1234567890123456781))
>w $d(^zzz(1234567890123456789))
>w $d(^zzz(1234567890123456785))

While test3 above did not suffer from the rouding error of the previous examples, I found, as shown
below, that when I attempted to access this global from the GTM command line, only the last set
was "visible" and it was not correct.

GTM>w $zv
GT.M V4.3-FT04 Linux x86
GTM>s ref="^zzz("""")"

GTM>s ref=$q(@ref) w !,ref

GTM>w $d(@ref)
GTM>w @ref

This is a fairly serious problem for us (VMTH, UC Davis) because we are attempting to replicate all
of our data on GTM and replace our existing DTM server. In order to transition smoothly to GTM,
we are hoping to host all of our DTM client systems from a GTM sever using OMI.


  • Nergis Dincer

    Nergis Dincer - 2001-12-12

    Logged In: YES

    In order to use DTM OMI clients with a GT.CM (OMI) server,
    you need to build GT.M with the following definition:
    define mval2subsc rc_mval2subsc

    Please note that, with GT.M clients, you should not have
    this definition.


  • Edwin Clubb

    Edwin Clubb - 2001-12-15

    Logged In: YES


    I modified the sr_unix/mdefsp.h file as follows:

    #ifdef __linux__
    #define mval2subsc rc_mval2subsc /* added to fix numeric subscript errors in DTM */
    #define OFF_T_LONG

    I found this define already present in the __sparc section of the file, so I presumed that this was where it should go.
    I recompiled GTM in versions 4.2 and 4.3, and found no difference in bahaviour when I run GT.CM -- I still am
    getting the same numeric subscript errors as before. Is there somewhere else that I need to include this define?

  • Sam Weiner

    Sam Weiner - 2001-12-24

    Logged In: YES


    Sorry for taking so long. On the first problem of differences in subscripts when using DTM OMI
    and versus GT.M directly, I am attaching a patch file which can be applied to V4.3-000. This
    is in addition to the #define mval2subsc Nergis suggested. This patch should not be applied
    if DTM OMI will not be used.

    We did some rearranging of the OMI code and build procedure a while back and this slipped
    through the cracks. Our other OMI user currently uses a version of GT.M which predates
    this change.

    As I read the M standard, only 15 digits of significance are required. GT.M provides 18 digits.
    It appears to leave undefined what happens with bigger numbers. Does your application have
    numeric subscripts (or literals) with more than 18 digits?

    Hope this helps, Sam

  • Sam Weiner

    Sam Weiner - 2001-12-24
    • assigned_to: nobody --> weiner
  • Sam Weiner

    Sam Weiner - 2001-12-24

    Patch needed for OMI

  • Edwin Clubb

    Edwin Clubb - 2001-12-28

    Logged In: YES


    Thanks for the patch. I thought your reply was very prompt, considering the season. The patch does appear to
    resolve my problem, although not in the way that I think it was intended to.

    After applying the patch, recompiling and testing with and without the #define mval2subsc statement, I discovered
    that my orignial analysis of the problem was wrong: the invalid $data values in the example I gave were caused by
    the DTM client rounding numeric subscripts to 16 significant digits.

    However, the reason I jumped to this conclusion is that unpatched version of GTM uses a different version of the
    mval2subsc function in gtcm_server from the one in the mumps executable. The version linked into gtcm_server
    limits numeric subscripts to 15 significant digits. This caused 16 digit numerics from the DTM client to be stored
    as a strings in GTM and fall out of the numeric collating sequence. When I attempted to compare globals in DTM
    datasets with those copied to the GTM server by doing side-by-side $queries (on the DTM client), I would not find
    the 16 digit subscripts, even though $data would return true. And because the mumps executable supports 18
    digit numerics, $data would report false for the same values (since they were really being stored as strings) on the
    GTM server. From this, I incorrectly concluded that $data was rounding down to the previous 15 digit subscript
    (which was present the first few times I encounted this problem).

    The mumps executable seems to have problems with the 16 digit subscripts that are stored as strings: the %G
    utility and the ZWRITE command would frequently either get stuck in a loop when attempting to display globals
    containg these subscripts, or fail to display the subscripts at all (as I noted in my example above). This is true
    even with the patch applied and the #define mval2subsc statement present.

    With the patch applied, but the #define mval2subsc statement NOT present, both gtcm_server and mumps are
    supporting 18 digit values, and I can store and retrieve all the DTM numeric subscripts via OMI without any
    problems. So, it appears that my problem is solved. Thanks again.



Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks