![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The trace file will be created in the default directory of the OSIF$GTWY account.
The trace file created may then be formatted using ositrace as discussed in Section 5.8.1.
$ define osak_trace on
RUN SYS$SYSTEM:VT_RESPONDER.EXE
At this point, the VT responder is executing in your process context, and eight (or the value specified by the VT$VT_RJOBLIM logical name) resp_xxxx.bin files will be created in your current directory.
As each new connection made to the VT responder terminates, a new resp_xxxx.bin file is created, and a previous resp_xxx.bin file now contains trace information. This is done in a first in, first out manner; the oldest .bin file contains the trace of the first association, the next youngest contains the second association, and so on.
Once you have collected all of the required trace data, use Ctrl/C and terminate the VT responder. Any resp_xxxx.bin files with a size of 0 may be deleted. Resp_xxxx.bin files which have non-zero sizes may be analyzed using ositrace (see Section 5.8.1 for more information).
The regular VT responder may now be restarted using the SYS$STARTUP:VT_START.COM procedure.
The VT/LAT or VT/TELNET gateways may also be traced in a similar manner by copying VTPAD.EXE to VT_LAT_GTWY.EXE or VT_TELNET_GTWY.EXE respectively.
The LAT/VT or TELNET/VT gateways may be traced by copying VTPAD.EXE to LAT_VT_GTWY.EXE or TELNET_VT_GTWY.EXE respectively. However, the trace files produced will be named init_xxxx.bin to reflect the fact that we are now acting as an initiator.
Open systems transmit PCI and file data in the form of octet strings. For each component being traced, the tracing utility logs the octets of PCI, file data, or both, sent or received by that component. The trace utility transcribes the octets into a sequence of hexadecimal digits. For PCI data, the utility also translates the data into ASN.1 (abstract-syntax notation). These translations correspond to the PCI definition of the component's service primitives. PCI definitions are part of the protocol specification of each FTAM or Virtual Terminal component.
You can compare tracing output to the corresponding PCI definition, to determine whether the encoding of PCI data is correct and whether the parameter values are valid. You can also compare the actual sequences of parameters with the valid sequences defined by the protocol. For information about FTAM and VT components, see your FTAM and Virtual Terminal documentation.
The readable file that the ositrace utility creates contains the following information about the protocol data units (PDUs) for each traced layer (see the example in this section and in Appendix B):
Trace Example
(1) 10:11:57.08 OSI trace started Wed Jan 30 10:11:57 1992
(2) 10:11:58.20 (3) --> (4) Session
(5) 0dff0148 05061301 00160102 14020002 33028080 34020103 c1ff0130 3180a080
80010100 00a28081 02808082 020103a4 80308002 01010605 28c27b02 01308006
02510100 00000030 80020103 060528c2 7b020230 80060251 01000000 00308002
01050605 28c27b02 03308006 02510100 00000030 80020107 060528c2 7b020430
80060251 01000000 00308002 01090606 2bce0f01 02023080 06025101 00000000
30800201 0b060452 01000130 80060251 01000000 00000088 02060089 03054000
61803080 02010ba0 7b6080a1 80060528 c27b0101 0000a280 06052bce 0f070100
00a38002 01010000 be802880 020101a0 4da08082 01008302 03408403 05070085
02058086 0100a780 4e0528c2 7b05014e 0528c27b 05024e05 28c27b05 034e062b
ce0f0105 09000056 0776696e 63656e74 710a1908 6e69636b 73746572 00000000
00000000 00000000 00000000
(6) connect-spdu 0d ff 01
connect/accept-item 05 06
protocol-options = NULL 13 01
version-number = 2 16 01 02
session-user-requirements = '0000000000000010'B 14 02 00
( duplex functional unit )
calling-ssap-identifier = 33 02 80
called-ssap-identifier = 34 02 01
user-data c1 ff 01
| Step | Action |
|---|---|
| 1 |
Check that the initiator ID (user name) is a valid identifier on the
responder's system.
For the FTAM responder, the initiator ID must be a valid user name for that system. If the user name requires a password, it must be supplied as well. |
| 2 |
Check that the filestore password is a valid account password for the
user name. For a Digital FTAM responder, the filestore password must be
the same as the login password.
Not all FTAM vendors map the filestore password to the login password. If using FTAM products other than Digital's, check the appropriate documentation for further information. |
| 3 | If an account field is being sent to the FTAM responder on an OpenVMS system, check that the field is valid (0 to 8 characters). |
| 4 |
On OpenVMS, check that the remote account specified by the initiator
has read and execute access to the responder account's login command
file.
On OpenVMS systems, if there is no login command file, check that the symbol LGICMD points at NL: (the null device). |
| 5 | On OpenVMS, check that the remote account specified by the initiator has read and execute access to the responder command file (i.e., osif$responder.com). |
| 6 | Check that the protection on input directories and files allows remote reading. |
| 7 | Check that the protection on output directories allows remote writing. |
| 8 |
Check the following in the local database file:
|
On OpenVMS systems, when specifying a foreign file name, you must enclose the name in double quotation marks (" "), so RMS does not parse the name. Enclose the file name in double quotation marks to preserve the case of the file name. It is best to ensure that all file names are in uppercase.
On UNIX systems, when specifying foreign file names, you must enclose the name in single quotation marks (' ').
Be aware that case sensitivity may be an issue when transferring files between OpenVMS and UNIX systems.
If copied files appear to have extra characters, the remote FTAM implementation may be having problems handling the ISO 8859 character set. You can identify this problem if you display a file and see repeated escape sequences in the data. These escape sequences are the ISO 8859 character set identifiers. The remote FTAM implementation should have handled these. Refer to the supplier of that implementation for further information.
Other file problems may be related to the way the file was transferred. Problems can occur if the requested format is unsupported. The FTAM implementation must convert the file to a supported format before it can transfer it properly (see your FTAM management documentation). If an FTAM file on an OpenVMS system file does not look correct, the software probably transferred it as an FTAM-3 file, which is the default format.
Do the following to check FTAM file formats:
| On OpenVMS Systems: | On Digital UNIX Systems: |
|---|---|
|
Enter this command:
$ dir/application_protocol=ftam/full filename |
Enter this command:
% ols -A application-name::file |
The displayed record tells you the format of the file, which can be:
| Step | Action |
|---|---|
| 1 |
Check that the
osak$server_v3.exe process (OpenVMS systems only) or the
ftam_listener process (Digital UNIX systems only) is running.
Do the following:
|
| 2 |
If necessary, start the
osak$server_v3.exe process (OpenVMS only) or the
ftam_listener process (Digital UNIX only) by doing one of the
following:
|
| 3 |
Invoke NCL and use the command
show node to see if the OSI transport software is running. For
example:
ncl> show node 0 osi transport state If OSI transport is running, NCL displays a message stating that the status state equals on. For example: Show Node 0 OSI Transport
If OSI transport is not running, NCL displays a message stating that the status state equals off. For example: Show Node 0 OSI Transport
|
| 4 |
If OSI transport is not running, do one of the following:
|
| 5 |
Check that the underlying DECnet software is running. From a privileged
account, type the following at the NCL prompt:
ncl> show session control state
The state should be On. |
| 6 | If you want to make a connection over an X.25 or Internet network from an OpenVMS system, you must have the X.25 software installed and running. |
If no error messages appear when you try to establish a connection but the connection attempt fails, create an initiator trace for the command that failed, as described in Section 5.8.
Use the procedures in the following sections if errors appear.
If the message is Address in Use, do the following:
| Step | Action |
|---|---|
| 1 |
Examine
/etc/isoapplications for incorrect entries. Check that all
entries contain the appropriate components and delimiters.
If you find errors, correct them and retry the operation. If the file is correct, go to step 2. |
| 2 |
Check that another process is not listening on the same transport
address. Do the following:
|
If the message is Network is unreachable, check that a listener/responder process is running on the remote node that can accept your connection request. There may be no way to reach the remote node.
Also, verify that the transport provider specified by the initiating entry is available on the responding entity.
If the message is Connection refused, the Transport layer received a disconnect from the remote system. Retry the operation or specify a different remote node. You can also check a trace, if it exists, for a diagnostic message that indicates why the remote system refused the connection.
If the message is Connection timed out, the remote node did not respond to your connection request. There may be no way to reach the remote node or no responder listening on the specified address.
Use the procedures in this section if an FTAM or VT responder on an OpenVMS system either terminates unexpectedly or will not start.
Try the following if an FTAM or Virtual Terminal responder on OpenVMS systems terminates unexpectedly:
| Step | Action |
|---|---|
| 1 | Examine the operator log for events prior to the failure. If indicated, change system parameters. |
| 2 | If no error exists in the operator log, or if changing system parameters does not correct the problem, perform a trace of the operation. |
| 3 | Check that there are no problems with the OSI transport provider (see Chapter 7). |
Try the following if an FTAM or Virtual Terminal responder on OpenVMS systems will not start:
| Step | Action |
|---|---|
| 1 |
Use the DCL command
show system to check that a responder is not already running
on the same node.
The application startup file usually prevents this from happening; check the startup file to see if it was incorrectly modified. |
| 2 | Check the alias database to see if another application is using the same TSAP. |
| 3 | Check that there are no problems with the OSI transport provider (see Chapter 7). |
Try the following if you have FTAM or Virtual Terminal responder problems on Digital UNIX systems:
| Step | Action |
|---|---|
| 1 | If the responder does not start, check the /usr/adm/syslog.dated/*/daemon.log file for errors that the ftam_listener or vt_listener generated. If no errors exist, go to step 2. |
| 2 | Start the responder (using ftamd or ologind) at the terminal and use the tracing option to generate a trace file. |
| 3 | Correct errors indicated by the trace file. |
| 4 | Make sure the addresses and transport options specified in the /etc/isoapplications file are correct. |
FTAM connections to remote systems can fail if the OpenVMS environment is not set up correctly. If any connections fail, first check that the size of the sysgen parameter, maxbuf, is at least 2048.
If inbound connections fail, check the following items in your OpenVMS environment:
| Step | Action |
|---|---|
| 1 |
Check the address database:
|
| 2 | Make sure the responder's default directory has write access and sufficient space for writing log files. |
| 3 |
Check the local account where the responder runs to see that:
|
| 4 | Check to see if maximum activity levels are being exceeded for networking processes, transport connections, X.25 connections, and other processes. |
| 5 |
Check the disk to make sure it:
|
Connections can fail if a problem with a specific service access point exists. The following procedures describe how to correct problems in the OSI layers.
Do the following to verify that the network topology can reach the remote system:
| Step | Action |
|---|---|
| 1 |
On OpenVMS systems only, look at the DECnet OPCOM messages to
check that the remote system is available.
On Digital UNIX systems only, check the /usr/adm/syslog.dated/*/daemon.log file. |
| 2 | Check that the physical network wires are connected. |
Use NCL commands to do the following:
For Direct X.25 Access:
| Step | Action |
|---|---|
| 1 |
Check that the physical address in use is correct. Do the following:
|
PS_PROFILE_005.HTML OSSG Documentation 2-DEC-1996 12:34:19.97
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.