DECnet-Plus
Problem Solving

5.18.3 Correcting FTAM and VT Transport Problems

Do the following to correct transport problems:

Step	Action
1	Check that the transport selectors for the initiator and responder match. The transport selector is the right-hand selector in an upper-layer address. On OpenVMS systems, display any upper-layer address defined for a responder or initiator. For example: For inbound connections, use the NCL command show osak application paddress. For outbound connections, check the file sys$system:isoapplications.dat. On Digital UNIX systems, check the /etc/isoapplications* file.
2	Check the format of the TSAP value to see if it is hexadecimal or ASCII.
3	Make sure that timers are not causing a disconnect too quickly; for example, the keepalive timer of the network service should be used.
4	Check that the correct transport template name is in use.
5	If you use Internet, check the addresses used and routing table entry.
6	If you use null Internet, check the OSI transport template to see if the inactive area address supplied matches the routing circuit.
7	Look at the transport counters to see if the transport software is working. See your DECnet-Plus management documentation for further information.

5.18.4 Correcting FTAM and VT Session Problems (OpenVMS Only)

Do the following to correct FTAM and VT problems at the Session layer on OpenVMS systems:

Step Action

1 Check that the session selectors for inbound and outbound connections match.
The session selector is the middle selector in an upper-layer address.

For inbound connections, if you need addressing information for the FTAM responder, use the NCL command show osak application.

For outbound connections, check the file sys$system:isoapplications.dat.

2 Check that the session versions of the two systems are compatible.
An FTAM responder can accept either version 1 or 2. If both versions are proposed on an F-INITIALIZE indication, the responder chooses version 2. By default, an FTAM initiator proposes version 2. However, you can override the default by entering version 1 or versions 1 and 2 into the alias entry for a given remote application.
To define the session version for an alias, edit the alias entry in sys$system:isoapplications.dat.

3 Check whether the values used are hexadecimal or ASCII, and whether the values are correct.

Step	Action
1	Check that the session selectors for inbound and outbound connections match. The session selector is the middle selector in an upper-layer address.
	For inbound connections, if you need addressing information for the FTAM responder, use the NCL command show osak application.
	For outbound connections, check the file sys$system:isoapplications.dat.
2	Check that the session versions of the two systems are compatible. An FTAM responder can accept either version 1 or 2. If both versions are proposed on an F-INITIALIZE indication, the responder chooses version 2. By default, an FTAM initiator proposes version 2. However, you can override the default by entering version 1 or versions 1 and 2 into the alias entry for a given remote application. To define the session version for an alias, edit the alias entry in sys$system:isoapplications.dat.
3	Check whether the values used are hexadecimal or ASCII, and whether the values are correct.

5.18.5 Correcting FTAM and VT Presentation Problems (OpenVMS Only)

Do the following to correct connection problems at the Presentation layer:

Step Action

1 Check that the presentation selectors on the initiator and responder systems match.
The presentation selector is the left-hand selector in an upper-layer address.

For inbound connections, if you need addressing information for the FTAM responder, use the NCL command show osak application.

For outbound connections, check the file sys$system:isoapplications.dat.

2 Check if there are common syntaxes for ACSE-PCI, FTAM-PCI, FTAM-FADU, unstructured binary, and unstructured text. FTAM uses the basic encoding rules of a single ASN.1 type as its transfer syntax.

3 Check whether the values used are hexadecimal or ASCII, and whether the values are correct.

Step	Action
1	Check that the presentation selectors on the initiator and responder systems match. The presentation selector is the left-hand selector in an upper-layer address.
	For inbound connections, if you need addressing information for the FTAM responder, use the NCL command show osak application.
	For outbound connections, check the file sys$system:isoapplications.dat.
2	Check if there are common syntaxes for ACSE-PCI, FTAM-PCI, FTAM-FADU, unstructured binary, and unstructured text. FTAM uses the basic encoding rules of a single ASN.1 type as its transfer syntax.
3	Check whether the values used are hexadecimal or ASCII, and whether the values are correct.

5.19 Correcting Problems with Applications Using OSAK

OSI application failures can indicate that a problem exists with their use of the OSI Applications Kernel (OSAK) software. Check the application's documentation to determine if the application has any dependencies on the OSAK software or uses the OSAK application programming interface.

Refer to the following documentation for more information about OSAK software and the OSAK application programming interface:

DECnet-Plus network management documentation
OSAK Programming and Programming Reference documentation
Documentation for any applications that use the OSAK software

5.19.1 Correcting Connection Problems

Do the following if an application that uses OSAK software has connection problems:

Step Action

1 Use the Common Trace Facility or the OSAK trace utility to get a transport trace and examine the output for the following:

Check that a transport connection was established. There should be a Connect Confirm (CC) transport protocol data unit (TPDU) in the trace.
If no CC TPDU exists, and the application uses the OSAK programming interface, check that the called_aei parameter that the initiator supplies matches the local address of the responder.
Check that the Data Transfer (DT) protocol data unit (PDU) containing the upper-layer connect was received.

2 If possible, examine the application's log file to check that the local application received the upper-layer connect.

3 Check that quotas were not exceeded.

Step	Action
1	Use the Common Trace Facility or the OSAK trace utility to get a transport trace and examine the output for the following: Check that a transport connection was established. There should be a Connect Confirm (CC) transport protocol data unit (TPDU) in the trace. If no CC TPDU exists, and the application uses the OSAK programming interface, check that the called_aei parameter that the initiator supplies matches the local address of the responder. Check that the Data Transfer (DT) protocol data unit (PDU) containing the upper-layer connect was received.
2	If possible, examine the application's log file to check that the local application received the upper-layer connect.
3	Check that quotas were not exceeded.

5.19.2 Correcting Unexpected Termination Problems

Do the following if the application terminates unexpectedly:

Step Action

1 Check the OSAK event sink (OpenVMS only) or the NCL event sink (Digital UNIX only) for evidence of protocol errors.

2 Create a transport trace using the OSAK trace utility, with the Errors option enabled.
If errors exist, report them to the originator of the PDU; this is the local system for outbound messages and the remote system for inbound messages. There can be errors in the PDU that tracing cannot detect, so you cannot assume that the PDU is correct even if no errors are reported.
If no errors exist, check the lower layers of your network.

Step	Action
1	Check the OSAK event sink (OpenVMS only) or the NCL event sink (Digital UNIX only) for evidence of protocol errors.
2	Create a transport trace using the OSAK trace utility, with the Errors option enabled. If errors exist, report them to the originator of the PDU; this is the local system for outbound messages and the remote system for inbound messages. There can be errors in the PDU that tracing cannot detect, so you cannot assume that the PDU is correct even if no errors are reported. If no errors exist, check the lower layers of your network.

5.19.3 Correcting Programming Problems

Do the following for programming problems:

Step Action

1 Check that optional parameters are set to null.

2 Make sure you have sufficient workspace.

3 Check that you have allocated enough buffers.

4 Make sure that the application checks returned status information.

Step	Action
1	Check that optional parameters are set to null.
2	Make sure you have sufficient workspace.
3	Check that you have allocated enough buffers.
4	Make sure that the application checks returned status information.

Chapter 6
Solving Session Control Problems

This chapter describes how to isolate and correct Digital Network Architecture (DNA) application faults that can be a result of a Session Control problem. DNA application failures can also be a result of:

Application-specific problems (refer to the application's documentation)
Name service problems (see Section 6.10)

Topics In This Chapter

The topics in this chapter are:

Underlying Components for Session Control (OpenVMS Only) (Section 6.1)
Underlying Components for Session Control (Digital UNIX Only) (Section 6.2)
Symptoms of Session Control Problems (Section 6.3)
Isolating Session Control Faults (Section 6.4)
Correcting Unknown Application Problems (Section 6.5)
Correcting Application Too Busy Problems (Section 6.6)
Correcting Access Control Problems (Section 6.7)
Correcting Insufficient Resource Problems (Section 6.8)
Correcting Timed Out Problems (Section 6.9)
Correcting Node Name Resolution Problems (Section 6.10)
Examining the DECnet-Plus Naming Cache (OpenVMS Only) (Section 6.11)

6.1 Underlying Components for Session Control (OpenVMS Only)

Figure 6-1 shows the direct underlying components that the Session Control software on OpenVMS systems use. Use this information as a guide during fault isolation.

Figure 6-1 Underlying Components for Session Control (OpenVMS)

6.2 Underlying Components for Session Control (Digital UNIX Only)

Figure 6-2 shows the direct underlying components that the Session Control software on Digital UNIX systems use. Use this information as a guide during fault isolation.

Figure 6-2 Underlying Components for Session Control (Digital UNIX)

6.2.1 References

Refer to your application's documentation if you determine that an application-specific problem caused a failure. Refer to Section 6.10 if you determine that a name service problem caused a failure.

6.3 Symptoms of Session Control Problems

The symptoms in Table 6-1 indicate that the local system attempted to establish a connection to the remote system, but a problem with the Session Control software, or with the naming information that Session Control uses, prevented the requested operation from completing.

Table 6-1 Symptoms of Session Control Problems
Symptom Possible Problem See:

Unknown application at remote node or object is unknown at remote node The address that the application used does not match the data in the Session Control application database on the remote node. Section 6.5

You attempted to connect to the wrong node.

Access control rejected Proxy access is not defined correctly. Section 6.7

Node name validation on source node failed or an invalid user name or password was used. Section 6.7.3

Application too busy The remote node is receiving too many connection requests before the application or the Session Control software can process them. Section 6.6

Remote node is unreachable Incompatible tower information exists for the source and destination node. Section 6.10

Session Control has insufficient resources Maximum number of available ports are all in use. Section 6.8

Timed out Local cache did not contain the correct information and Session Control took too long to retrieve naming information from a remote server. Section 6.9 or Section 6.10

Outgoing or incoming request timer is set too low.

Server application does not declare itself (for example, on an OpenVMS system, when the application used IO$ACPCONTROL, GET_CONNECTION or during process creation).

Wrong information displayed or wrong account accessed Proxy entries on local node do not match those on the remote node and the system logs you in to a default user account. Section 6.7.2 or 6.7.1

Unable to obtain the address for a node The name service is not available.
The name service search path is not correctly set up.
Section 6.10

**Table 6-1 Symptoms of Session Control Problems**
Symptom	Possible Problem	See:
Unknown application at remote node or object is unknown at remote node	The address that the application used does not match the data in the Session Control application database on the remote node.	Section 6.5
	You attempted to connect to the wrong node.

Access control rejected	Proxy access is not defined correctly.	Section 6.7
	Node name validation on source node failed or an invalid user name or password was used.	Section 6.7.3

Application too busy	The remote node is receiving too many connection requests before the application or the Session Control software can process them.	Section 6.6

Remote node is unreachable	Incompatible tower information exists for the source and destination node.	Section 6.10

Session Control has insufficient resources	Maximum number of available ports are all in use.	Section 6.8

Timed out	Local cache did not contain the correct information and Session Control took too long to retrieve naming information from a remote server.	Section 6.9 or Section 6.10
	Outgoing or incoming request timer is set too low.
	Server application does not declare itself (for example, on an OpenVMS system, when the application used IO$ACPCONTROL, GET_CONNECTION or during process creation).

Wrong information displayed or wrong account accessed	Proxy entries on local node do not match those on the remote node and the system logs you in to a default user account.	Section 6.7.2 or 6.7.1

Unable to obtain the address for a node	The name service is not available. The name service search path is not correctly set up.	Section 6.10

6.4 Isolating Session Control Faults

Session Control problems can be the cause of DNA application failures that are not application specific. Session Control problems can occur because of:

Name service problems (see Section 6.10)
Session Control entity problems
Transport layer problems (see Chapter 7)
Network layer problems (see Chapter 8)

Before trying any correction procedures, do the following to isolate the problem to the appropriate area:

Step Action

1 Try to establish a connection using a different application.
If the connection succeeds, an application-specific problem exists. Refer to the documentation for the application that failed.
If the connection attempt fails, Session Control cannot complete the connection request. Continue fault-isolation procedures to determine if the problem is caused by the namespace operation, Session Control entity problems, or a lower-layer problem.

2 Check whether the remote node is reachable. Use quick reachability or loopback tests or trace the network path between the nodes. Or, try using a different source node to connect to the remote node.
If the source node cannot reach the remote node, check the nodes in the path to determine the problem.
If the remote node is reachable, go to the next step.

3 Attempt to connect to the remote node using the remote node's address.
If the connection succeeds, check the naming information that Session Control uses. See Section 6.10.
If the connection fails, check the lower-layer operation on the local and remote node (see Chapters 7 and 8).

Step	Action
1	Try to establish a connection using a different application. If the connection succeeds, an application-specific problem exists. Refer to the documentation for the application that failed. If the connection attempt fails, Session Control cannot complete the connection request. Continue fault-isolation procedures to determine if the problem is caused by the namespace operation, Session Control entity problems, or a lower-layer problem.
2	Check whether the remote node is reachable. Use quick reachability or loopback tests or trace the network path between the nodes. Or, try using a different source node to connect to the remote node. If the source node cannot reach the remote node, check the nodes in the path to determine the problem. If the remote node is reachable, go to the next step.
3	Attempt to connect to the remote node using the remote node's address. If the connection succeeds, check the naming information that Session Control uses. See Section 6.10. If the connection fails, check the lower-layer operation on the local and remote node (see Chapters 7 and 8).

6.4.1 Tools and Commands to Use

To:	Use This Tool or Command:
Quickly confirm that remote node is reachable.	set host or dlogin with node address. If test succeeds, examine your DECdns namespace or local database.
Confirm the remote node is reachable.	Loopback tests, see Section 3.1.1
Examine the Session Control component.	NCL Session Control commands
Check naming information.	Trace facility, see Section 6.10

6.4.2 Fault-Isolation Methodology

Use Figure 6-3 as a guideline for isolating Session Control faults.

Figure 6-3 Fault-Isolation Methodology (Session Control)

6.5 Correcting Unknown Application Problems

This type of message can appear if:

The end-user specifications on the target system do not match the end-user specifications that the application uses on the originating system.
The file that an application invokes on an incoming request exists and the account using it cannot execute the file.

Check that you (or the application) used the correct node name. If the correct node name was used, do the following to fix this problem:

Step Action

1 Use the following NCL command to get information about applications that activate an image file or command procedure when they receive incoming requests (referred to as initiator applications):
ncl>show session control application * -
_ncl>all characteristics

2 Examine the display for the following information:

Address -- This is the application's object names or numbers. number=XX indicates the object number; name=xxx indicates the object = 0, with the specified name.
User name -- This is the account under which the application runs for default access.
Image name -- This is the file that is the target for the connection.

3 Identify the applications that are daemons (referred to as declared responders). Use one of the following NCL commands:
For OpenVMS systems:

ncl> show session control port * all attributes, -
_ncl> with creation time > timestamp
ncl> show session control port * all attributes, -
_ncl> with direction=incoming

For Digital UNIX systems:

ncl>show session control port * all attributes, -
_ncl> with creation time > timestamp
ncl>show session control port * all attributes, -
_ncl> with direction=listening

4 Identify the local end user address. This address is the object name or number of the application. Use the following NCL command:
ncl> show session control port * -
_ncl>local end user address

5 Check the following:

The value of the Address attribute and the object name or number that the originator of the incoming request used match these values on the remote node.
The file indicated by the Image Name field:

If the file does not exist, copy it from another location or reinstall the application.
If the account specified in the User Name field cannot access the file, change the file's access so the account can use it.

The value of the Local End User Address field and the object name or number that the originator of the incoming request used match these values on the remote node.

Step	Action
1	Use the following NCL command to get information about applications that activate an image file or command procedure when they receive incoming requests (referred to as initiator applications): ncl>show session control application -* _ncl>all characteristics
2	Examine the display for the following information: Address -- This is the application's object names or numbers. number=XX indicates the object number; name=xxx indicates the object = 0, with the specified name. User name -- This is the account under which the application runs for default access. Image name -- This is the file that is the target for the connection.
3	Identify the applications that are daemons (referred to as declared responders). Use one of the following NCL commands: For OpenVMS systems: ncl> show session control port all attributes, -* _ncl> with creation time > timestamp ncl> show session control port all attributes, -* _ncl> with direction=incoming For Digital UNIX systems: ncl>show session control port all attributes, -* _ncl> with creation time > timestamp ncl>show session control port all attributes, -* _ncl> with direction=listening
4	Identify the local end user address. This address is the object name or number of the application. Use the following NCL command: ncl> show session control port -* _ncl>local end user address
5	Check the following: The value of the Address attribute and the object name or number that the originator of the incoming request used match these values on the remote node. The file indicated by the Image Name field: If the file does not exist, copy it from another location or reinstall the application. If the account specified in the User Name field cannot access the file, change the file's access so the account can use it. The value of the Local End User Address field and the object name or number that the originator of the incoming request used match these values on the remote node.

6.6 Correcting Application Too Busy Problems

If you occasionally receive an application too busy problem, retry the operation after a short wait. If you frequently receive this message, do the following:

Step Action

1 Refer to the application's documentation to determine if the application is configured properly.

2 On Digital UNIX systems: Check the maximum instance characteristic for the application. Use the following NCL command:
ncl>show session control application -
_ncl> application-id all.
If the maximum instances characteristic is equal to any value other than 0, it may be set too low. Use the following NCL command to reset this characteristic:
ncl> set session control application -
_ncl> application-id maximum instance value

Step	Action
1	Refer to the application's documentation to determine if the application is configured properly.
2	On Digital UNIX systems: Check the maximum instance characteristic for the application. Use the following NCL command: ncl>show session control application - _ncl> application-id* all. If the maximum instances* characteristic is equal to any value other than 0, it may be set too low. Use the following NCL command to reset this characteristic: ncl> set session control application - _ncl> application-id maximum instance value

6.7 Correcting Access Control Problems

Access control problems can occur if proxy access is not enabled correctly or if the software cannot find or validate specified node names. Do the following to determine what type of access control problem you have:

Step	Action
1	Make sure the user name that you or an application use is defined in the application or object database on the remote node.
2	Check to see if the failed application is checking for proxy access. For OpenVMS systems, see Section 6.7.1. For Digital UNIX systems, use an NCL command similar to one of the following to look at the session control ports in use: ncl>show session control port proxy requested, -* _ncl>with direction=listening If the proxy requested status is false, either the application did not request proxy access or outgoing proxy on the remote node is not enabled. Refer to the application's documentation or the following proxy access correction procedures.
3	Check the session control tower maintenance database to ensure the node is registered correctly. Use the following NCL command: ncl>show node node-id* session control tower -* _ncl> maintenance name* all* You can use an asterisk () instead of the name* to display information for all nodes.

Step

Action

Make sure the user name that you or an application use is defined in the application or object database on the remote node.

Check to see if the failed application is checking for proxy access.

For OpenVMS systems, see Section 6.7.1. For Digital UNIX systems, use an NCL command similar to one of the following to look at the session control ports in use:

ncl>show session control port * proxy requested, -
_ncl>with direction=listening

If the proxy requested status is false, either the application did not request proxy access or outgoing proxy on the remote node is not enabled. Refer to the application's documentation or the following proxy access correction procedures.

Check the session control tower maintenance database to ensure the node is registered correctly. Use the following NCL command:

ncl>show node node-id session control tower -
_ncl> maintenance name all

You can use an asterisk (*) instead of the name to display information for all nodes.

6.7.1 Correcting Proxy Access Problems (OpenVMS Only)

Do the following to check the proxy access:

Step Action

1 Invoke the authorize utility and use the following command to check the proxy account:
uaf>show/proxy *

2 If the proxy account is not set up correctly, use authorize commands to reset the proxy account values.

3 If you cannot access the proxy account, check to see if Session Control created an intrusion record for your client account on the target node. Issue the following DCL command:
$ show intrusion

4 If login attempts exceed the set acceptable number of times for the system, a break-in record will exist and the system may have disabled the account. Check the account using the authorize utility to see if the account was disabled.

Step	Action
1	Invoke the authorize utility and use the following command to check the proxy account: uaf>show/proxy *
2	If the proxy account is not set up correctly, use authorize commands to reset the proxy account values.
3	If you cannot access the proxy account, check to see if Session Control created an intrusion record for your client account on the target node. Issue the following DCL command: $ show intrusion
4	If login attempts exceed the set acceptable number of times for the system, a break-in record will exist and the system may have disabled the account. Check the account using the authorize utility to see if the account was disabled.

6.7.2 Correcting Proxy Access Problems (Digital UNIX Only)

Do the following to correct proxy access problems:

Step	Action
1	Look at the Outgoing Proxy characteristic on the originating node (client system). Use the following NCL command: ncl>show session control outgoing proxy
2	If the Outgoing Proxy characteristic on the originating node is FALSE, use the following NCL command to change it to TRUE: ncl>set session control outgoing proxy true
3	Look at the Incoming Proxy characteristic on the target node. Use the following NCL commands: ncl>show session control incoming proxy ncl>show session control application _ncl> application-id incoming proxy
4	If the Incoming Proxy characteristic on the target node is set to FALSE, use the following NCL commands to change it to TRUE: ncl>set session control incoming proxy true ncl>set session control application - _ncl> application-id* incoming proxy true*
5	Check that Session Control Proxy entities are defined correctly. Use the following NCL command: ncl> show session control proxy name* -* _ncl>all characteristics Look at the following characteristics: Target user -- Should specify a valid account on the target system. Applications -- If empty, any application can use the proxy. If applications are listed, only those applications can use the proxy. Type -- If explicit, the originating system must specify a target user name that matches the target name of the proxy entry. If default, the originating system does not need to specify a target user name. Source end users -- Must specify the source node and user name that matches the source node and user name on the originating system.
6	If proxy entry on remote node is not defined correctly, modify existing proxy entry. Use NCL commands similar to the following: ncl>set session control proxy - _ncl> simple-name* target user latin1-string, -* _ncl>type default ncl> set session control proxy simple-name* -* _ncl>source end users - _ncl>{[Node= node-id,End User= address]}
7	If you need to allow more than one end user to use the proxy entry, add additional source end-user information. Use the following NCL command: ncl>add session control proxy simple-name* -* _ncl>source end users - _ncl>{[node = node-id, EndUser= id]}

  PS_PROFILE_006.HTML
  OSSG Documentation
   2-DEC-1996 12:34:21.94

Legal

DECnet-PlusProblem Solving