IBM 26K6477 User Guide - Page 80

SMASH, Proxy, nonaddressing, associations, supported, physical, logical, targets

Get IBM 26K6477 PDF manuals and user guides View all IBM 26K6477 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 80 highlights

Table 25. LED functions (continued) Function Command See the status of all LEDs on a show /modularX/switchY/oemiicmled* copper pass-through module Table 26. Help functions Function Get help on the SMASH implementation in general Get help on a particular verb Get help on a particular target Show the version of the SMASH implementation in general Command help help [verb] or [verb] -help help [target] version Notes Where X can be any UFiT index returned by a show /modular* command and Y corresponds to the bay where the copper pass-through module resides. Notes SMASH Proxy nonaddressing associations and supported physical and logical targets As described in "Addressing association diagrams" on page 19, objects link to each other through associations. An addressing association means that you can use it to target an object with the following addressing format: [parent object]/[object] For example, admin1/hdwr1 . Nonaddressing associations, however, cannot be used with a [parent object]/[object] syntax. For example, as shown in Table 27 on page 65, chassisX, with a UFiP of /hdwr1/chassisX, has a nonaddressing SystemPackaging association to modularX. Because it is a nonaddressing association, you cannot address modularX as /hdwr1/chassisX/modularX. Instead, you must address it as /modularX, directly. To target the SystemPackaging association itself, the address would be /hdwr1/chassisX=>SystemPackaging=>/modularX. The following tables show all SMASH Proxy supported object types and their associated verbs and nonaddressing associations. For all tables: v Each object is indicated by bold font. v An object's subcomponent is indicated by example font. v A subcomponents subcomponent is indicated by italic font. v The next level of subcomponent is indicated by ″quotes″. v Further granularity of a subcomponent is underlined. Note: The file paths for some target UFiPs and targets of nonaddressing associations have been broken in order to fit them in the table. There are no spaces between UFiTs in UFiPs. They are in the form: /modularX/capacities1/configcapacityY 64 SMASH Proxy Installation and User's Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
Table
25.
LED
functions
(continued)
Function
Command
Notes
See
the
status
of
all
LEDs
on
a
copper
pass-through
module
show
/modularX/switchY/oemiicmled*
Where
X
can
be
any
UFiT
index
returned
by
a
show
/modular*
command
and
Y
corresponds
to
the
bay
where
the
copper
pass-through
module
resides.
Table
26.
Help
functions
Function
Command
Notes
Get
help
on
the
SMASH
implementation
in
general
help
Get
help
on
a
particular
verb
help
[verb]
or
[verb]
-help
Get
help
on
a
particular
target
help
[target]
Show
the
version
of
the
SMASH
implementation
in
general
version
SMASH
Proxy
nonaddressing
associations
and
supported
physical
and
logical
targets
As
described
in
“Addressing
association
diagrams”
on
page
19,
objects
link
to
each
other
through
associations.
An
addressing
association
means
that
you
can
use
it
to
target
an
object
with
the
following
addressing
format:
[parent
object]/[object]
For
example,
admin1/hdwr1
.
Nonaddressing
associations
,
however,
cannot
be
used
with
a
[parent
object]/[object]
syntax.
For
example,
as
shown
in
Table
27
on
page
65,
chassisX,
with
a
UFiP
of
/hdwr1/chassisX,
has
a
nonaddressing
SystemPackaging
association
to
modularX.
Because
it
is
a
nonaddressing
association,
you
cannot
address
modularX
as
/hdwr1/chassisX/modularX.
Instead,
you
must
address
it
as
/modularX,
directly.
To
target
the
SystemPackaging
association
itself,
the
address
would
be
/hdwr1/chassisX=>SystemPackaging=>/modularX.
The
following
tables
show
all
SMASH
Proxy
supported
object
types
and
their
associated
verbs
and
nonaddressing
associations.
For
all
tables:
v
Each
object
is
indicated
by
bold
font.
v
An
object’s
subcomponent
is
indicated
by
example
font.
v
A
subcomponents
subcomponent
is
indicated
by
italic
font.
v
The
next
level
of
subcomponent
is
indicated
by
″
quotes
″
.
v
Further
granularity
of
a
subcomponent
is
underlined.
Note:
The
file
paths
for
some
target
UFiPs
and
targets
of
nonaddressing
associations
have
been
broken
in
order
to
fit
them
in
the
table.
There
are
no
spaces
between
UFiTs
in
UFiPs.
They
are
in
the
form:
/modularX/capacities1/configcapacityY
64
SMASH
Proxy
Installation
and
User's
Guide