STDC abend with Arithmetic Overflow Trap - UTL^GET^DISC^MEAS^REC - Process over restart limit DISCOL

[Support_Sydney]

WVLOG Event: STDC ... Arithmetic Overflow Trap - ... UTL^GET^DISC^MEAS^REC

Example WVLOG event:
2010-02-17 16:08:58 00015005 STDC 01,802 TAL 00000 8.5.0
Arithmetic Overflow Trap - 4640 UTL^GET^DISC^MEAS^REC

This may also appear:
2010-02-17 16:09:07 00001035 IRPROMGR 01,132 PROMGRP 05528 8.5.0
Process is over restart limit DISCCOLISCCOL

[Support_Sydney · Accepted solution]

WVLOG Event: STDC ... Arithmetic Overflow Trap - ... UTL^GET^DISC^MEAS^REC

Example WVLOG event:
2010-02-17 16:08:58 00015005 STDC 01,802 TAL 00000 8.5.0
Arithmetic Overflow Trap - 4640 UTL^GET^DISC^MEAS^REC

This may also appear:
2010-02-17 16:09:07 00001035 IRPROMGR 01,132 PROMGRP 05528 8.5.0
Process is over restart limit DISCCOLISCCOL

It actually appears to be due to a HP problem where the MEASREADACTIVE() call has an unhandled overflow. HP have advised us to use the newer MEAS_READACTIVE_ call available in versions G09 and later of Measure to obtain the same data. Currently this STDC code change is under consideration for a future release of PROGNOSIS.
This is caused by a long running MEASURE. The workaround is to stop all measurements on DISC entities (in and outside PROGNOSIS). Once they are all stopped, then the measure counters should be reset, and the problem should go away. To do this:

1. Shutdown PROGNOSIS
2. Stop any VIEWPOINT measurements if there are any.
3. check for any other DISC measurements:
a. MEASCOM
b. STATUS MEASSUBSYS

For each active measurement:
c. ADD MEASUREMENT < measurement filename>
d. INFO MEASUREMENT < measurement filename>
e. If the DISC entity is seen, then stop this measurement, then check the next (ie: repeat c., d. and e.).

4. Once this is done, restart PROGNOSIS and check if the problem has now gone away. You can also restart viewpoint if you wish.
Verified several times at various custgomers' sites, but it could take a system 11 to 15 months before it happens.