Hello,
I'm sure that there was at least a few discussions with "smcomps". In one of them I posted a message - I can't find it anymore. It was DevCon discussion in Service Impact Manager area.

In other discussion there was a post with description of "smcomps" primitive. I made a copy of it:
========================================
The smcomps() primitive returns a list of pointers to the components that are in the impact path or the cause path of a selected component. Various parameters can be used to refine that list.

The smcomps() primitive makes it possible to retrieve, manage and propagate a list of impacted CIs or causal CIs from within the rules of a KB.

smcomps (ParamNameList, ParamValueList, Comp1List, ShadowList, Comp2List)
ParamNameList = (IN) List of parameter names
ParamValueList = (IN) List of parameter values
Comp1List = (OUT) List of primary search components
ShadowList = (OUT) List of shadow components
Comp2List = (OUT) List of secondary search components

List of Parameters

• comp = BMC_AssetBase.mc_udid of focus component
• dir = direction: cause or impact ( c | i )
• impact = Impact type: true or possible ( t | p )
• events = Boolean: False or True ( F | T )
• ext = Boolean: False or True ( F | T )
• leaf = Boolean: False or True ( F | T )
• type = Component class

Parameters’ default values

comp=0, dir=c, impact=p, leaf=F, events=F, ext=F, type=BMC_AssetBase


The smcomps() primitive retrieves components, starting with the focus component identified by comp, in direction dir. The other parameters influence the inclusion of a component, and the continuation of the search.
A component is included if all of the following conditions hold:
• component is of class type (or a sub-class of it)
• if pending events are requested (events=T), the component must have self_status!=NONE
• if leaf nodes are requested (leaf=T), at least one of the following conditions must hold :
o component has a manual status (i.e. manual_status!=NONE)
o component has self_status>impact_status
o component has consolidate_function=SELF_PREFERRED

In an impact direction search, shadowed components (i.e. with shadow_cells not empty), are always included, regardless of the above conditions.
The search is terminated if any of the following conditions hold:
• if true impact is requested (impact=t) and the relationship does not have true_impact=YES
• if the component is included because it has a manual status
• if the component is included because it has self_status>impact_status

If an extended search is requested (ext=T), and the primary search is terminated at the focus component, a secondary search is performed, continuing after the focus component, under the same conditions.
The result value Comp1List is a list of pointers to CORE_DATA instances. Since the CORE_DATA class only contains the mc_udid slot, a second rule will be necessary if there is a need to access other SIM slots (like Name or Priority) in that context.
The two other result values ShadowList and Comp2List are typically not used in the MRL context at this stage.
========================================

Regards,

Mariusz