April 2002 - Libsmi - lists.ibr.cs.tu-bs.de

Errors while accessing it in DLL
by Save, Amit Prabhakar (Amit) 16 Apr '02

16 Apr '02

Hi, I have created one lib instead of creating smidump.exe. The main fn. in smidump.c was renamed to smiDumpMain(). So that I could access it inside my code as a Library rather than to run it as a command. I hope till this everything is fine? When I try to use it in my code, at the time of linking I get errors as Mibcompiler.obj : error LNK2001: unresolved external symbol __imp__smiDumpMain When I was building an EXE of my code making a call to smiDumpMain(), everything used to work fine. I have ran the code also & it works fine. But if I build a DLL of my code making a call to smiDumpMain(), the above error comes up. Regards, Amit Save

1 0

Warning given is correct??
by Vivekanandan V 08 Apr '02

08 Apr '02

Hello, I have defined the SYNTAX of one mib objects as "InetAddressIPv4" - Imported from INET-ADDRESS-MIB. The smilint tool gives an warning that "'InetAddress' should be used instead of `InetAddressIPv4". What is the meaning of this warning?? Is this warning correct?? Thanks & Regards, Vivekanandan.V *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************

2 1

problem in tool when checking the access of Index elements
by Vivekanandan V 05 Apr '02

05 Apr '02

Hello, Iam having an Index element which is also an OBJECT for an NOTIFICATION-TYPE object. And Iam having the MAX-ACCESS of this Index element as "accessible-for-notify". The smilint tool gives an warning that "Index element should be not-accessible", which is wrong for this case. So an extra check should be put for this also. Regards, Vivekanandan.V *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************

3 4

Re: [libsmi] problem in tool when checking the access of Index elements
by Frank Strauss 05 Apr '02

05 Apr '02

Hi! Vivekanandan> Iam having an Index element which is also an OBJECT for Vivekanandan> an NOTIFICATION-TYPE object. And Iam having the Vivekanandan> MAX-ACCESS of this Index element as Vivekanandan> "accessible-for-notify". The smilint tool gives an Vivekanandan> warning that "Index element should be not-accessible", Vivekanandan> which is wrong for this case. So an extra check should Vivekanandan> be put for this also. An interesting situation! :-) However, RFC 2578, Section 7.7 doesn't allow another MAX-ACCESS value than not-accessible in this case. Your MIB should not use the not-accessible index object in the notification type's OBJECTS clause, but another column of the conceptual table. And in most cases this even makes sense :-): Notifications are raised on specific conditions. You usually want to carry not only the instance information but also some information about this condition, e.g. the current status on a status change notification or a current rate on a threshold notification. -frank

1 0

Suggestion....
by Vivekanandan V 05 Apr '02

05 Apr '02

Hi, It will be very useful for us, if the new Release details, bug-fixes made,.... in the smilint tool can be announced in this mailing list itself. Thanks & Regards, Vivekanandan.V *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************

1 0

Clarification req......
by Vivekanandan V 03 Apr '02

03 Apr '02

Hello, In Isis mib (draft-ietf-isis-wg-mib-05.txt), the objects of a table are not assigned continuous OID's. Please let me know, whether this is correct or whether continuous OID's must only be assigned to Table elements. Thanks & Regards, Vivekanandan.V *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************

2 1