OSI/MHS Configuration and Management Manual

Planning Your OSI/MHS Subsystem
OSI/MHS Configuration and Management Manual—424827-003
3-14
Priorities
With link retry, if all the links fail and the link-retry time expires, no report or error event
message is produced.
OSI/MHS records each link retry in the InternalTraceInformation field of the X.400
message. It records each route retry in the TraceInformationElement field of the X.400
message.
Adjust the RETRY-TIME attributes as needed to prevent retries from consuming too
much processing power and memory. Undelivered reports, in particular, become larger
with each retry. It is a good idea to set retry values for reports separately from those
for probes and messages, so that you can specify longer retry cycles and a shorter
expiration time.
Priorities
When you configure alternate routes, you must also set their priorities. In Figure 3-4,
you would configure route 1 with a priority of 1 and route 2 with a priority of 2. You
specify priorities with the PRI attribute of the ADD ROUTE command.
Priority values are relative only to the priorities of other routes for a particular O/R
name. These values do not have to start with 1 and do not have to increase in
increments of 1.
Verification
To verify that you have set up your route-selection criteria accurately, you may want to
try only a few routes at first and see if they work. If you start with a simple
configuration, then you can build upon it in segments and test each segment as you
build.
If problems occur, the subsystem will generate nondelivery reports and accounting
events and messages. When you execute a STATS PROCESS MRP command, you
will see specific reports generated, rather than messages successfully relayed. When
this occurs, you should review the accounting events and your routing specifications.
How Will You Set Up Your GI, LO, MR, MS, and
RS Groups?
Each OSI/MHS subsystem can have multiple GI, LO, MR, MS, and RS groups. In
determining the total number of groups you need, consider your requirements for
recovery, resilience, and expandability.
Recovery Considerations
A group fails when any one of its processes fails or when a CPU on which any of its
processes are running fails. For recovery, it is recommended that you keep all the
processes of a group within one CPU because the group runs as a unit. If you spread
the processes among many CPUs and any CPU fails, the entire group fails.