Resource Object Data Manager and GMFHS Programmer’s Guide

Examples of Collection Definition Objects

This section contains examples of the Collection Definition Objects.

Example 1:

Collect all objects in the GMFHS_Managed_Real_Objects_Class whose DisplayStatus field is not equal to 129 and show them in a Network View. The vertical bar character (|) serves as the separator character on the CollectionSpec1 field.

The CDO object that describes this collection can be specified as follows in a RODM loader file:

     CREATE INVOKER  ::= 0000003;
          OBJCLASS ::= Network_View_Collection_Class;
          OBJINST  ::= MyName = (CHARVAR) 'Example1';
          ATTRLIST
          Annotation ::= (CHARVAR) 'Example1 Annotation',
          LayoutType ::= (INTEGER) 1,
          CollectionSpec1 ::=
            (CHARVAR) '|GMFHS_Managed_Real_Objects_Class|
                                    DisplayStatus|129|.NE.';
     END;

This RODM Collection Manager creates a Network_View_Class object called "Example1" with a LayoutType of 1 and Annotation of "Example1 Annotation". The collection specification represents a single conditional (it is composed of a single leaf specification). The matching object list is copied to the ContainsObject field of the Example1 view.

Example 2:

Collect all objects in the appnTransmissionGroupCircuit class (actual class name is 1.3.18.0.0.2058) whose DisplayResourceOtherData field contains a CP as the first two characters, and Active as the last six characters AND all objects in the appnTransmissionGroupCircuit class whose AggregationPriorityValue is equal to 1, 2, or 3 , and put them into an Aggregate. The vertical bar character (|) serves as the separator character.

The CDO object that describes this collection can be specified as follows in a RODM loader file:

CREATE INVOKER  ::= 0000003;
          OBJCLASS ::= Aggregate_Collection_Class;
          OBJINST  ::= MyName = (CHARVAR) 'Example2';
          ATTRLIST
          DisplayResourceOtherData ::= (CHARVAR) 'Example2 Other Data',
          DisplayResourceUserData ::= (CHARVAR) 'Example2 User Data',
          CollectionSpec1 ::=
            (CHARVAR) '|1.3.18.0.0.2058|DisplayResourceOtherData|
                                        CP*Active|.CONTAINS=.',
          CollectionSpec2 ::=
            (CHARVAR) '|1.3.18.0.0.2058|AggregationPriorityValue|
                                        1|2|3|.EQ.|.AND.';
     END;

The RODM Collection Manager creates a GMFHS_Aggregate_Objects_Class object called Example2 with a DisplayResourceOtherData of "Example2 Other Data" and a DisplayResourceUserData of "Example2 User Data". The other fields that are not specified on the Aggregate_Collection_Class object are set to the defaults used for objects created on the GMFHS_Aggregate_Objects_Class.

The collection specification is represented in both of the CollectionSpecn fields. It can be placed entirely in either the CollectionSpec1 or CollectionSpec2 field; this example demonstrates the concatenation of the two fields. The actual collection specification, after concatenation, is:

|1.3.18.0.0.2058|DisplayResourceOtherData|CP*Active|.CONTAINS=.|1.3.18.0.0.2058|
AggregationPriorityValue|1|2|3|.EQ.|.AND.

This collection specification represents a complex conditional (it is composed of a two leaf specifications). DOS wildcards are used to find the objects that match the DisplayResourceOtherData value. If there are three objects in class 1.3.18.0.0.2058 with objects IDs 1, 2, and 3, and their corresponding DisplayResourceOtherData fields contain:

CPCP-supportedActive
CP-CP Session Support
CPCP-supportedNotActive

and their corresponding AggregationPriorityValue fields contain:

-1
2
3

After evaluating the first leaf specification, the virtual stack contains:

{1, 3}

where {1, 3} is the object list produced from evaluating the leaf specification. After evaluating the second leaf specification, the virtual stack contains:

{2, 3}
{1, 3}

The .AND. conjunction causes the two object lists to be removed from the stack; their intersection results in the list {3} which is added to the stack. This object is the result of the entire complex conditional. It is linked into both the AggregationChild field (using the DUIFCUAP method) and the IsPartOf field on the Example2 object.

There is no benefit using two different classes in the individual leaf specifications. Both leaf specifications, by definition, produce object lists that contain no objects in common. The intersection of the lists requested by the .AND. conjunction therefore always produces an empty object list. If the conjunction is .OR., then using two different classes is acceptable.

Example 3:

Collect all objects in the GMFHS_Managed_Real_Objects class whose MyName matches TEST plus an alphabetic classification character plus some number of additional characters plus 1 plus a numeric range character; for example, "TESTACPU10", as long as the alphabetic classification character is not B, and whose DisplayStatus is either Satisfactory or Unsatisfactory. Add to this list the objects in the GMFHS_Aggregate_Objects_Class whose MyName matches TEST plus an alphabetic classification character plus some number of additional characters, for example, "TESTACPUALL", as long as the alphabetic classification character is not B. Enter them into a Network View.

The CDO object that describes this collection can be specified as follows in a RODM loader file:

CREATE INVOKER  ::= 0000003;
       OBJCLASS ::= Network_View_Collection_Class;
       OBJINST  ::= MyName = (CHARVAR) 'Example3';
       ATTRLIST
       Annotation ::= (CHARVAR) 'Example3 Annotation',
       CollectionSpec1 ::=
          (CHARVAR) '|GMFHS_Managed_Real_Objects_Class|MyName|\^TEST[A-C].*1.$|
                            .CONTAINS.'
                      '|GMFHS_Managed_Real_Objects_Class|MyName|TESTB*|
                            .NCONTAINS.|.AND.'
                      '|GMFHS_Managed_Real_Objects_Class|DisplayStatus|130|
                            .LE.|.AND.'
                    '|GMFHS_Aggregate_Objects_Class|MyName|\^TEST[A-C].*$|
                            .CONTAINS.'
                      '|GMFHS_Aggregate_Objects_Class|MyName|TESTB*|
                            .NCONTAINS.|.AND.|.OR.';   END;

Assume the following objects exist in the GMFHS_Managed_Real_Objects_Class:

Object ID	MyName	DisplayStatus
1	TESTACPU10	131
2	TESTACPU11	129
3	TESTBCPU10	130
4	TESTBCPU11	132
5	TESTCCPU10	129
6	TESTCCPU11	132
7	TESTCCPU12	129
8	TESTCCPU12X	130
9	TESTDCPU10	129

Assume the following objects exist in the GMFHS_Aggregate_Objects_Class:

Object ID	MyName
10	TESTAAGGs
11	TESTBAGGS
12	TESTCAGGS
13	TESTDAGGS

The expression for the first leaf specification is given in regular expression notation. DOS wildcards do not have a way to specify that the 5th character must be between A and C, so the regular expression was used in this case. After evaluating the first leaf specification, the virtual stack contains:

 {1, 2, 3, 4, 5, 6, 7}

After evaluating the second leaf specification, the virtual stack contains:

 {1, 2, 5, 6, 7, 8, 9}
        {1, 2, 3, 4, 5, 6, 7}

The .AND. conjunction removes these two lists from the stack, and replaces them with:

 {1, 2, 5, 6, 7}

After evaluating the third leaf specification, the virtual stack contains:

 {2, 3, 5, 7, 8, 9}
 {1, 2, 5, 6, 7}

The .AND. conjunction removes these two lists from the stack, and replaces them with:

 {2, 5, 7}

After evaluating the fourth leaf specification, the virtual stack contains:

 {10, 11, 12}
 {2, 5, 7}

After evaluating the fifth (and final) leaf specification, the virtual stack contains:

 {10, 12, 13}
 {10, 11, 12}
 {2, 5, 7}

The .AND. conjunction removes the top two lists from the stack, and replaces them with:

 {10, 12}
 {2, 5, 7}

Finally, the .OR. conjunction removes only two lists from the stack, and replaces them with:

 {2, 5, 7, 10, 12}

This becomes the final object list returned by the complex conditional which is then linked in to the ContainsObjects field of the Example 3 object.