NetXMS Support Forum

First of all I wish a happy new year to all of you contributing to this excellent product!

After upgrading from 2.1.2 to 2.2.1 on Windows (Server 2012 R2) we encountered "bad arithmetic conversion" errors or wrong values on specific DCI's related to IBM bladecenter values. All these values share the fact that they were initially STRING's in the MIB saying something like "16.00 Centigrades" or "50% of maximum".

The Data Type of the DCI was set to "Floating Point Number" and the string was manipulated by a transformation rule stripping the characters out of the value:

sub main()
{
p = index( $1, "Centigrade");
return 0.0 + trim(substr( $1, 1, p-1));
}

This worked fine before 2.2.1. Now the "bad arithmetic conversion" errors fire up.

In researching what happened the verdict came up that the conversion now happens before the translation rule even gets fired. Getting a STRING for a DCI as initial value with data type "Floating Point Number" gets a NULL value as $1 into the Translation rule.

So we had to come up with a workaround...

We use two DCI entries with the respective sample Descriptions:
1) temperatureSTR : data type = STRING, we don't do conversion - the recorded value e.g. is "18.00 Centigrade"
2) temperature : data type = Floating Point Number - As parameter we use a newly created script (GetFloatDCIValue) put into the script library with two parameters, the Description of the string parameter 1) (in this case "temperatureSTR") and the text to strip out. --> GetFloatDCIValue("temperatureSTR", "Centigrade")

Here is the script (placed in the Script Library):

xf = GetDCIValueByDescription( $node, $1);
p = index( xf, $2 );
if (p==0)
{
return -1;
}
else
{
return 0.0 + trim(substr( xf, 1, p-1));
}


I spent some hours to evaluate and fix it for us as we have several systems and dashboards that rely on those values. I'm not sure that my workaround is the best approach, but I was happy to come out with a working solution.

However, I would suggest changing this behavior back to preserve the implicit conversion philosophy of the platform. Again thank you for this great product.

Hi,

we fix it in 2.2.2. Since 2.2.1 server does forced type conversion of input value to DCI's data type - that helps in situation when DCI is 64 bit integer for example but input value is small and detected as 32 bit integer. Now conversion will took place only if input value is a valid numerical value - otherwise it will be passed as string as before.

Best regards,
Victor