T.R | Title | User | Personal Name | Date | Lines |
---|
3858.1 | Buffer overflow reading alarms data file. | COPCLU::EBC | | Wed Nov 11 1992 10:12 | 9 |
| Any answers to this ?
I am seeing the same problem.
VMS is 5.5-1, MCC is 1.2.
In the input-datafile the Managed object specification is followed by
appr. 1000 spaces!
regards,
Erik B. Christensen
|
3858.2 | Please report bugs through QARs | TOOK::MINTZ | LKG2-2 near pole X3, cube 6072, dtn 226-5033 | Wed Nov 11 1992 12:18 | 2 |
| Sounds like this should be handled through the QAR system. See note 7.
|
3858.3 | QAR 539 V1.2 ext | CTHQ::WOODCOCK | | Thu Nov 12 1992 13:42 | 1 |
| QAR 539 V1.2 ext
|
3858.4 | SNMP-object record always 1039 bytes long? | COPCLU::EBC | | Mon Nov 23 1992 09:29 | 20 |
| More info from my investigation:
The "DCL-W-BUFOVF" error is generated by one of the lexical functions
(f$search or f$extract) in the mcc_alarms_log_alarm.com procedure.
The error occurs when reading the record "MANAGED OBJECT" which for an
SNMP object is 1039 bytes long (The object name + app. 1000 spaces +
a 1 (ascii 31)).
On our internal MCC-system, the "managed object"-record is also 1039
bytes for an SNMP-entity, but I don't get any errors in the log-file.
Records for NODE4-entities are only as long as the object-name + 1
space.
Since our system has the same SW-versions (VMS 5.5-1, MCC 1.2) as our
customers, and I don't get the error here, the error cannot be caused
by the record length alone.
Erik B. Christensen
|
3858.5 | The bug has been fixed | TRM::KWAK | | Tue Dec 01 1992 17:35 | 7 |
|
Thanks for finding the problem.
The fix has been made (today), and will be available in the V1.3 Field
Test Update kit.
William
|