
Hello everybody
I have a couple of issue, according with my own MIB file.
I can divide error on 4 section: 1)
[4] {group-membership} warning: node `Location' must be contained in at least one conformance group
2)
[5] {group-unref} warning: current group `DNSGroup' is not referenced in this module
3)
[2] {parent-scalar} scalar's parent node must be simple node
4)
[5] {row-name-table-name} warning: row identifier `MetersTableEntry' should have the same prefix as table identifier `MetersTable'
I cannot show my MIB File, but will try to explain it structure. I have about 100 nodes. Several of them are unite in groups, another - not. All of them consist in 2 main groups, which make connection with module-identity.
In short I have follow structure: MODULE-IDENTITY -> OBJECT IDENTIFIER (2 different objects) | | | |-------> OBJECT-TYPE (several nodes) | | | |-------> TABLE (with index and several nodes OBJECT-TYPE) | |-----------> OBJECT-TYPE (several nodes) | |-----------> OBJECT-GROUP (several group) | |
|---------> OBJECT-TYPE (several nodes)
1 section of error I have before MIB modification with adding OBJECT-GROUP. After adding groups I have received 2 and 3 section of errors. 4 section error regard only with table implementation. I have found all section of this errors on http://www.icir.org/fenner/mibs/htmllint/ and have checked all errors on this page http://www.icir.org/fenner/mibs/libsmi-errors, but unfortunately have not found any correct explanation how to fix those errors, except this one http://www.icir.org/fenner/mibs/libsmi-errors/group-membership.html . I have tried to understand RFC, but without any success. Also I have tried to compile MIB with specific soft, like MG-SOFT http://www.mg-soft.si/ and it show only 4 section of error. I need to know if those warnings/errors are critical and if they can be fixed and how. All errors show on http://www.simpleweb.org/ietf/mibs/validate/ and http://www.ibr.cs.tu-bs.de/bin/smitools.cgi with severity level 3,4,5 and 6. During creation my own MIB file I have used for example DISMAN-PING-MIB which has not any errors in those online checks.
If it's needed I will send my MIB file for better understand the issue.
Thank you in advance. I will be glad for any help.
WBR, Evgheni.

On Wed, Sep 26, 2012 at 12:05:40PM +0300, Evgheni Antropov wrote:
Hello everybody
I have a couple of issue, according with my own MIB file.
I can divide error on 4 section:
[4] {group-membership} warning: node `Location' must be contained in at least one conformance group
[5] {group-unref} warning: current group `DNSGroup' is not referenced in this module
[2] {parent-scalar} scalar's parent node must be simple node
[5] {row-name-table-name} warning: row identifier `MetersTableEntry' should have the same prefix as table identifier `MetersTable'
I need to know if those warnings/errors are critical and if they can be fixed and how. All errors show on http://www.simpleweb.org/ietf/mibs/validate/ and http://www.ibr.cs.tu-bs.de/bin/smitools.cgi with severity level 3,4,5 and
Here is an excerpt from the smilint manual page:
All generated error and warning messages have an associated severity level. The actual severity levels are:
0 Internal error, no recovery possible. Examples are memory allocation failures. Errors of this level usually cause the application to abort.
1 Major SMI/SPPI error, recovery somehow possible but may lead to severe problems. Examples are lexically unexpected characters or unknown keywords. Errors of this kind usually lead to follow-on errors.
2 SMI/SPPI error which is probably tolerated by some implementations. Examples are MIB/PIB modules which mix constructs from different SMI/SPPI versions.
3 SMI/SPPI error which is likely tolerated by many implementations. Examples are misplaced SMIv2 MODULE-IDENTITY invocations or SMIv2 textual conventions derived from other textual conventions.
4 Something which is not strictly an error but which is recommended to be changed. Warnings of this level are usually considered during MIB reviews.
5 Something that is basically correct but might be problematic in certain environments or usage scenarios. Examples are warnings that identifiers only differ in case or that type definitions are not used within the defining module.
6 Messages of this level are auxiliary notices. Examples are messages that point to a previous definition in case of a redefinition.
Higher levels are currently not used and lead to the same effects as level 6 does. Note that errors up to level 3 are errors violating the specifications and must be fixed by the responsible author. The warnings generated with level 4 should be considered during normal MIB/PIB reviews.
This means only
[2] {parent-scalar} scalar's parent node must be simple node
really needs to be fixed. 1) and 2) relate to conformance definitions, which is important for standardized MIB modules but less so for proprietary MIB modules. 5) is a deviation from common naming conventions, does not really hurt but I personally would probably fix it an rename MetersTableEntry to MetersEntry (but then it must start with a lowercase letter - perhaps you removed some prefix before sending this to the list?).
/js

2012/9/26 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
Here is an excerpt from the smilint manual page:
All generated error and warning messages have an associated severity level. The actual severity levels are: 0 Internal error, no recovery possible. Examples are memory allocation failures. Errors of this level usually cause the application to abort. 1 Major SMI/SPPI error, recovery somehow possible but may lead to severe problems. Examples are lexically unexpected characters or unknown keywords. Errors of this kind usually lead to follow-on errors. 2 SMI/SPPI error which is probably tolerated by some implementations. Examples are MIB/PIB modules which mix constructs from different SMI/SPPI versions. 3 SMI/SPPI error which is likely tolerated by many implementations. Examples are misplaced SMIv2 MODULE-IDENTITY invocations or SMIv2 textual conventions derived from other textual conventions. 4 Something which is not strictly an error but which is recommended to be changed. Warnings of this level are usually considered during MIB reviews. 5 Something that is basically correct but might be problematic in certain environments or usage scenarios. Examples are warnings that identifiers only differ in case or that type definitions are not used within the defining module. 6 Messages of this level are auxiliary notices. Examples are messages that point to a previous definition in case of a redefinition. Higher levels are currently not used and lead to the same effects as level 6 does. Note that errors up to level 3 are errors violating the specifications and must be fixed by the responsible author. The warnings generated with level 4 should be considered during normal MIB/PIB reviews.
Yes, I understand that those errors is not critical, but have an idea to make how much correctly. For example, in DISMAN-PING-MIB which has similar structure I have not observed those errors. May be is any secret here ? Please show any links how to check normal MIB/PIB reviews
This means only
[2] {parent-scalar} scalar's parent node must be simple node
really needs to be fixed. 1) and 2) relate to conformance definitions, which is important for standardized MIB modules but less so for proprietary MIB modules. 5) is a deviation from common naming conventions, does not really hurt but I personally would probably fix it an rename MetersTableEntry to MetersEntry (but then it must start with a lowercase letter - perhaps you removed some prefix before sending this to the list?).
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/
Oh sorry, you are right in original I have following error message:
5warning: row identifier `aidMetersTableEntry' should have the same prefix as table identifier `aidMyMib-MetersTable' where aidMyMib is defined in follow record aidMyMib OBJECT IDENTIFIER ::= { MyMib 3 }
and all table is defined is follow way
-- Table of Meter's Characteristics
aidMyMib-MetersTable OBJECT-TYPE SYNTAX SEQUENCE OF AidMetersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table with management data " ::= { aidMyMib 11 }
aidMetersTableEntry OBJECT-TYPE SYNTAX AidMetersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Record describing the attributes of one meter. It is indexed by aidMeterIndex." INDEX { aidMeterIndex } ::= { aidMyMib-MetersTable 1 }
AidMetersTableEntry ::= SEQUENCE { aidMeterIndex MeterIndex, aidMeterST SystemTitle, aidMeterInfo OCTET STRING, aidMeterStatus OCTET STRING, aidMeterAlarms OCTET STRING, aidMeterLastResponse DateTime, aidMeterCommRate OCTET STRING }
aidMeterIndex OBJECT-TYPE SYNTAX MeterIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { aidMetersTableEntry 1 }
Unfortunately your advice has not helped to fix this issue.
Any suggestion ?
WBR, Evgheni

On Wed, Sep 26, 2012 at 01:08:31PM +0300, Evgheni Antropov wrote:
Yes, I understand that those errors is not critical, but have an idea to make how much correctly. For example, in DISMAN-PING-MIB which has similar structure I have not observed those errors. May be is any secret here ? Please show any links how to check normal MIB/PIB reviews
This means only
[2] {parent-scalar} scalar's parent node must be simple node
This _is_ an error to be fixed.
Oh sorry, you are right in original I have following error message:
5warning: row identifier `aidMetersTableEntry' should have the same prefix as table identifier `aidMyMib-MetersTable' where aidMyMib is defined in follow record
Well, as the error message says, the prefix of the *Table and *Entry objects should be the same. And get rid of the hyphen anyway.
/js

Oh sorry, you are right in original I have following error message:
5warning: row identifier `aidMetersTableEntry' should have the same
prefix
as table identifier `aidMyMib-MetersTable' where aidMyMib is defined in follow record
Well, as the error message says, the prefix of the *Table and *Entry objects should be the same. And get rid of the hyphen anyway.
/js
Great advice Juergen, it was fixed. Thank you very much.
I'm sorry for misunderstand, but you wrote: 2012/9/26 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
On Wed, Sep 26, 2012 at 01:08:31PM +0300, Evgheni Antropov wrote:
Yes, I understand that those errors is not critical, but have an idea to make how much correctly. For example, in DISMAN-PING-MIB which has
similar
structure I have not observed those errors. May be is any secret here ? Please show any links how to check normal MIB/PIB reviews
This means only
[2] {parent-scalar} scalar's parent node must be simple node
This _is_ an error to be fixed.
How is it fixed ? I have no idea, how to check the cause of this. May be
my MIB file will help to find solution (have made short variant): ========================================== MY-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, IpAddress, Integer32, enterprises FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC2579 OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 ;
myMib MODULE-IDENTITY LAST-UPDATED "201209240000Z" -- 24 September 2012 ORGANIZATION "company" CONTACT-INFO "Technical Support, service@company.com" DESCRIPTION "Contains OID definitions for devices MIB's."
-- Revision history
REVISION "201209240000Z" -- 24 September 2012 DESCRIPTION "MIB version 1.0: - Created separate group for every main configuration parameter. ::= { enterprises xxxxxxx }
-- ---------------------------------------------------------- -- -- Textual Conventions -- ---------------------------------------------------------- --
Boolean ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "True/False definition of expression" SYNTAX INTEGER { false(0), true(1) }
-- Top level structure of the MIB
aidProducts OBJECT IDENTIFIER ::= { myMib 1 } aid2Mib OBJECT IDENTIFIER ::= { myMib 2 } aid3Mib OBJECT IDENTIFIER ::= { myMib 3 }
-- ---------------------------------------------------------- --
aid2Mib-Node1 OBJECT-TYPE SYNTAX Boolean MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { aid2Mib 1 }
aid2Mib-Node2 OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { aid2Mib 2 }
aid2Mib-Node3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { aid2Mib 3 }
-- ---------------------------------------------------------- --
aid2MibCfg OBJECT-IDENTITY STATUS current DESCRIPTION "Sub-tree for configuration objects" ::= { aid2Mib 100 }
-- ---------------------------------------------------------- --
aid2MibCfg-Node1 OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..5)) MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid2MibCfg 1 }
aid2MibCfg-Node2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid2MibCfg 2 }
aid2MibCfgNodeGroup OBJECT-GROUP OBJECTS { aid2MibCfg-NodeGroup1, aid2MibCfg-NodeGroup2 } STATUS current DESCRIPTION "The root OID for DNS Settings." ::= { aid2MibCfg 50 }
aid2MibCfg-NodeGroup1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid2MibCfgNodeGroup 1 }
aid2MibCfg-NodeGroup2 OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..10)) MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid2MibCfgNodeGroup 2 }
aid2MibCfg-Node3 OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid2MibCfg 98 }
-- ---------------------------------------------------------- --
aid3Mib-Node1 OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..50)) MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { aid3Mib 1 }
aid3Mib-Node2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of meters in DC." ::= { aid3Mib 10 }
-- ---------------------------------------------------------- -- -- Table of Meter's Characteristics
aidMetersTable OBJECT-TYPE SYNTAX SEQUENCE OF AidMetersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { aid3Mib 11 }
aidMetersTableEntry OBJECT-TYPE SYNTAX AidMetersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { aidMeterIndex } ::= { aidMetersTable 1 }
AidMetersTableEntry ::= SEQUENCE { aidMeterIndex Index, aidMeterInfo OCTET STRING, }
aidMeterIndex OBJECT-TYPE SYNTAX Index MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { aidMetersTableEntry 1 }
aidMeterInfo OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "" ::= { aidMetersTableEntry 2 }
-- ---------------------------------------------------------- --
aid3MibCfg OBJECT-IDENTITY STATUS current DESCRIPTION "Sub-tree for configuration objects" ::= { aid3Mib 100 }
-- ---------------------------------------------------------- --
aid3MibCfg-Node1 OBJECT-TYPE SYNTAX Boolean MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid3MibCfg 1 }
aid3MibCfg-Node2 OBJECT-TYPE SYNTAX Boolean MAX-ACCESS read-write STATUS current DESCRIPTION "" ::= { aid3MibCfg 5 }
END
==========================================
Can you please check if this records haму corrected format.
Thank you in advance.
Evgheni

On Wed, Sep 26, 2012 at 02:36:52PM +0300, Evgheni Antropov wrote:
[2] {parent-scalar} scalar's parent node must be simple node
This _is_ an error to be fixed.
How is it fixed ? I have no idea, how to check the cause of this. May be
my MIB file will help to find solution (have made short variant):
No and here is why. I am not going to spent more of my time on this.
/tmp/aa:36: [1] syntax error, unexpected UPPERCASE_IDENTIFIER, expecting COLON_COLON_EQUAL /tmp/aa:36: [1] lexically unexpected character, skipping to end of line /tmp/aa:164: [1] syntax error, unexpected '}', expecting LOWERCASE_IDENTIFIER /tmp/aa:204: [2] missing MODULE-IDENTITY clause in SMIv2 MIB /tmp/aa:41: [1] unknown object identifier label `myMib' /tmp/aa:47: [2] type `Boolean' of node `aid2Mib-Node1' does not resolve to a known base type /tmp/aa:102: [2] scalar's parent node must be simple node /tmp/aa:109: [2] scalar's parent node must be simple node /tmp/aa:166: [2] type `Index' of node `aidMeterIndex' does not resolve to a known base type /tmp/aa:150: [1] illegal base type `Index' in index element `aidMeterIndex' of row aidMetersTableEntry /tmp/aa:190: [2] type `Boolean' of node `aid3MibCfg-Node1' does not resolve to a known base type /tmp/aa:197: [2] type `Boolean' of node `aid3MibCfg-Node2' does not resolve to a known base type /tmp/aa:49: [2] unknown type `Boolean' /tmp/aa:144: [2] unknown type `AidMetersTableEntry' /tmp/aa:162: [2] unknown type `Index'
/js

Thank you for your help.
Will try to find solution with own strength.
Thanks for your time
WBR, Evgheni.
2012/9/26 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
On Wed, Sep 26, 2012 at 02:36:52PM +0300, Evgheni Antropov wrote:
[2] {parent-scalar} scalar's parent node must be simple node
This _is_ an error to be fixed.
How is it fixed ? I have no idea, how to check the cause of this. May
be
my MIB file will help to find solution (have made short variant):
No and here is why. I am not going to spent more of my time on this.
/tmp/aa:36: [1] syntax error, unexpected UPPERCASE_IDENTIFIER, expecting COLON_COLON_EQUAL /tmp/aa:36: [1] lexically unexpected character, skipping to end of line /tmp/aa:164: [1] syntax error, unexpected '}', expecting LOWERCASE_IDENTIFIER /tmp/aa:204: [2] missing MODULE-IDENTITY clause in SMIv2 MIB /tmp/aa:41: [1] unknown object identifier label `myMib' /tmp/aa:47: [2] type `Boolean' of node `aid2Mib-Node1' does not resolve to a known base type /tmp/aa:102: [2] scalar's parent node must be simple node /tmp/aa:109: [2] scalar's parent node must be simple node /tmp/aa:166: [2] type `Index' of node `aidMeterIndex' does not resolve to a known base type /tmp/aa:150: [1] illegal base type `Index' in index element `aidMeterIndex' of row aidMetersTableEntry /tmp/aa:190: [2] type `Boolean' of node `aid3MibCfg-Node1' does not resolve to a known base type /tmp/aa:197: [2] type `Boolean' of node `aid3MibCfg-Node2' does not resolve to a known base type /tmp/aa:49: [2] unknown type `Boolean' /tmp/aa:144: [2] unknown type `AidMetersTableEntry' /tmp/aa:162: [2] unknown type `Index'
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/

Hello
We have decided to completely remake MIB file. After using soft from http://www.muonics.com/ we have corrected our MIB file and make structure, similar with another main mib files and related with SMIv2.
For current moment we have only that kind of errors 5 warning: current group `adxRTR7MainGroup' is not referenced in this module
[5] {group-unref} warning: current group `adxRTR7MainGroup' is not referenced in this module
I would appreciate, if anybody know how to resolve this error.
Thank you in advance.
Evgheni
2012/9/26 Evgheni Antropov aidjek@gmail.com
Thank you for your help.
Will try to find solution with own strength.
Thanks for your time
WBR, Evgheni.
2012/9/26 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
On Wed, Sep 26, 2012 at 02:36:52PM +0300, Evgheni Antropov wrote:
> > [2] {parent-scalar} scalar's parent node must be simple node >
This _is_ an error to be fixed.
How is it fixed ? I have no idea, how to check the cause of this. May
be
my MIB file will help to find solution (have made short variant):
No and here is why. I am not going to spent more of my time on this.
/tmp/aa:36: [1] syntax error, unexpected UPPERCASE_IDENTIFIER, expecting COLON_COLON_EQUAL /tmp/aa:36: [1] lexically unexpected character, skipping to end of line /tmp/aa:164: [1] syntax error, unexpected '}', expecting LOWERCASE_IDENTIFIER /tmp/aa:204: [2] missing MODULE-IDENTITY clause in SMIv2 MIB /tmp/aa:41: [1] unknown object identifier label `myMib' /tmp/aa:47: [2] type `Boolean' of node `aid2Mib-Node1' does not resolve to a known base type /tmp/aa:102: [2] scalar's parent node must be simple node /tmp/aa:109: [2] scalar's parent node must be simple node /tmp/aa:166: [2] type `Index' of node `aidMeterIndex' does not resolve to a known base type /tmp/aa:150: [1] illegal base type `Index' in index element `aidMeterIndex' of row aidMetersTableEntry /tmp/aa:190: [2] type `Boolean' of node `aid3MibCfg-Node1' does not resolve to a known base type /tmp/aa:197: [2] type `Boolean' of node `aid3MibCfg-Node2' does not resolve to a known base type /tmp/aa:49: [2] unknown type `Boolean' /tmp/aa:144: [2] unknown type `AidMetersTableEntry' /tmp/aa:162: [2] unknown type `Index'
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/

On Tue, Oct 02, 2012 at 12:29:18PM +0300, Evgheni Antropov wrote:
Hello
We have decided to completely remake MIB file. After using soft from http://www.muonics.com/ we have corrected our MIB file and make structure, similar with another main mib files and related with SMIv2.
For current moment we have only that kind of errors 5 warning: current group `adxRTR7MainGroup' is not referenced in this module
[5] {group-unref} warning: current group `adxRTR7MainGroup' is not referenced in this module
It is a _warning_, not an _error_. If you want to get rid of it, reference the adxRTR7MainGroup from a MODULE-COMPLIANCE macro invocation.
/js

Oh, yes. I thought in the same order. I know that those warnings are not important, but for my own satisfaction will try to add MODE-COMPLIANCE and check it. A lot of thanks Juergen for your help.
WBR, Evgheni
2012/10/2 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
On Tue, Oct 02, 2012 at 12:29:18PM +0300, Evgheni Antropov wrote:
Hello
We have decided to completely remake MIB file. After using soft from http://www.muonics.com/ we have corrected our MIB file and make
structure,
similar with another main mib files and related with SMIv2.
For current moment we have only that kind of errors 5 warning: current group `adxRTR7MainGroup' is not referenced in this module
[5] {group-unref} warning: current group `adxRTR7MainGroup' is not referenced in this module
It is a _warning_, not an _error_. If you want to get rid of it, reference the adxRTR7MainGroup from a MODULE-COMPLIANCE macro invocation.
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/

Yes, I did it.
Validation reportFile: ADDAX-MIB.txtSeverity level requested: 6 No errors/warnings found.
A lot of thanks for Juergen Schoenwaelder, without you I would have clinked during understanding MIB formats.
And thanks for guys from http://www.muonics.com/ for real full knowledge base and good software to work with MIB files.
WBR, Evgheni.
2012/10/2 Evgheni Antropov aidjek@gmail.com
Oh, yes. I thought in the same order. I know that those warnings are not important, but for my own satisfaction will try to add MODE-COMPLIANCE and check it. A lot of thanks Juergen for your help.
WBR, Evgheni
2012/10/2 Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de
On Tue, Oct 02, 2012 at 12:29:18PM +0300, Evgheni Antropov wrote:
Hello
We have decided to completely remake MIB file. After using soft from http://www.muonics.com/ we have corrected our MIB file and make
structure,
similar with another main mib files and related with SMIv2.
For current moment we have only that kind of errors 5 warning: current group `adxRTR7MainGroup' is not referenced in this module
[5] {group-unref} warning: current group `adxRTR7MainGroup' is not referenced in this module
It is a _warning_, not an _error_. If you want to get rid of it, reference the adxRTR7MainGroup from a MODULE-COMPLIANCE macro invocation.
/js
-- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/
participants (2)
-
Evgheni Antropov
-
Juergen Schoenwaelder