SSCPDYN=YES 
SSCPORD=PRIORITY 

VTAM adds entries dynamically to the adjacent SSCP table.
When establishing sessions in releases before VTAM®
Version 3 Release 2, VTAM gives priority to SSCPs for
which the most recent session initiation attempt
succeeded or for which no attempt has been made, even if
a more direct path to the CDRM that owns the destination
LU becomes available.
When establishing sessions, VTAM Version 3 Release 2
and later releases give priority to the CDRM that owns
the destination LU (if known), and then to SSCPs for
which the most recent session attempt succeeded.
This combination of options gives you the greatest
flexibility for setting up routes across networks, and,
if your adjacent SSCP table is large, it gives you the
best performance during session setup.

SSCPDYN=YES 
SSCPORD=DEFINED 

Entries are added dynamically to the adjacent SSCP table,
but VTAM always searches the table from top to bottom
when it tries to initiate a session.
Because the dynamic entries are added at the bottom of
the list, they are tried last during session initiation.
This combination of options results in increased session
setup time if the primary paths (those near the top of
the list) are not available.
But if a secondary path (one nearer the bottom of the
table) is used, it does not get priority for subsequent
sessions.

SSCPDYN=NO 
SSCPORD=PRIORITY 

No entries are added to the adjacent SSCP table, except
when the owner of a cross-domain resource is defined
explicitly by the CDRM operand of the CDRSC definition
statement.
Therefore, VTAM can use only the paths you define in the
table, and if one of these paths fails, VTAM does not
attempt to use it again until all other paths also fail.
This combination of options tends to limit the number
of available cross-network routes.
You might also need to define additional adjacent SSCP
tables because VTAM does not build them automatically
each time an application program issues a CLSDST PASS
macroinstruction for a cross-network session.

SSCPDYN=NO 
SSCPORD=DEFINED 

No entries are added to the adjacent SSCP table,
except when the owner of a cross-domain resource is
defined explicitly by the CDRM operand of the CDRSC
definition statement.
VTAM always searches the table from top to bottom when
it tries to initiate a session.
Again, VTAM can only use the paths you define in the
table; but, because VTAM always searches the table from
top to bottom, a path that fails can be used again as
soon as it is restored.
This combination of options results in increased session
setup time if the primary paths (those near the top of
the list) are not available.
But if a secondary path (one nearer the bottom of the
table) is used, it does not get priority for subsequent
sessions.
You might also need to define additional adjacent SSCP
tables because VTAM does not build them automatically
each time an application program issues a CLSDST PASS
macroinstruction for a cross-network session.
VTAM does not add new entries unless it is the owner
of the resource.  The owner is determined by the CDRM
operand of the CDRSC definition statement,
or by session initiation.