| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3946.1 | | RMULAC.DVO.DEC.COM::S_WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Tue Apr 29 1997 08:39 | 11 |
| What type of system are you copying too?
>%FTAM-E-ERR_PROTOCOL_SP, copy: protocol error on ending transfer
>%FTAM-E-ERR_UABORT, A user ABORT has been received
This suggests that the other system aborted the connection when we were trying
to end the transfer. We'll need the following:
o an FTAM trace
o A DIR/FULL of the source file
o an ANALYZE/RMS of the source file
|
| 3946.2 | The info requested... | STP01::STPVNV::stp01::voinov | Vladimir Voinov, MCS Russia | Mon May 05 1997 04:26 | 109 |
| Sorry, I was out for several days.
>What type of system are you copying too?
The customer says that the other side is running DECNET 6.3, ECO 3.
Below there is a list of the software, installed here:
$!DEC AXPVMS VMS V7.1 Oper System Available
$!DEC AXPVMS OPENVMS V7.1 Platform Available
$!DEC AXPVMS DECNET_OSI V7.1 Full LP Available
$!DEC AXPVMS X25 V1.1-B Full LP Available
$!DEC AXPVMS WANDD V1.1-B Full LP Available
$!DEC AXPVMS OSAK V3.0-P Full LP Available
$!DEC AXPVMS FTAM V3.2-L Full LP Available
$!DEC AXPVMS VT V2.1-H Full LP Available
> We'll need the following:
>o an FTAM trace
There is pretty large trace file (about 400 K), you could get it's zipped
version from STP01::SYS$SYSDEVICE:[FAL$SERVER]DELTA.ZIP.
>o A DIR/FULL of the source file
>o an ANALYZE/RMS of the source file
$dir CDSTP00FI00000146.; /full
Directory $1$DIA11:[DELTA_USER.EGOROV.NMT]
CDSTP00FI00000146.;1
File ID: (7254,1,0)
Size: 115/117
Owner: [MIS,VALERY]
Created: 30-APR-1997 11:23:22.48
Revised: 30-APR-1997 11:38:41.16 (1)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
File organization: Sequential
Shelved state: Online
File attributes:
Allocation: 117, Extend: 0, Global buffer count: 0, No version limit
Record format: Fixed length 80 byte records
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Total of 1 file, 115/117 blocks.
$define osak_trace on
$copy /app=ftam /log CDSTP00FI00000146. -
dannet"nmtstp00 caviar95"::CDSTP00FI00000146.
%FTAM-E-NOTCOPIED, $1$DIA11:[DELTA_USER.EGOROV.NMT]CDSTP00FI00000146.;1 not copied
%SYSTEM-E-LEN_NOTPAGMULT, specified length is not a multiple of CPU-specific pages
%FTAM-E-ERRSENPDU, Error sending a PDU, return code is 10002
%FTAM-E-UNKEVTVAL, Unknown state machine event (65)
%FTAM-E-ERR_PROTOCOL_SP, copy: protocol error on write
%FTAM-E-ERR_UABORT, A user ABORT has been received
%COPY-W-NOTCOPIED, $1$DIA11:[DELTA_USER.EGOROV.NMT]CDSTP00FI00000146.;1 not copied
$mcr ositrace INIT_350200_727725136.BIN 7_1_trace.txt
$analyze/rms/check CDSTP00FI00000146.;
Check RMS File Integrity 30-APR-1997
15:14:57.71 Page 1
$1$DIA11:[DELTA_USER.EGOROV.NMT]CDSTP00FI00000146.;1
FILE HEADER
File Spec: $1$DIA11:[DELTA_USER.EGOROV.NMT]CDSTP00FI00000146.;1
File ID: (7254,1,0)
Owner UIC: [MIS,VALERY]
Protection: System: RWED, Owner: RWED, Group: RE, World:
Creation Date: 30-APR-1997 11:23:22.48
Revision Date: 30-APR-1997 11:38:41.16, Number: 1
Expiration Date: none specified
Backup Date: none posted
Contiguity Options: none
Performance Options: none
Reliability Options: none
Journaling Enabled: none
RMS FILE ATTRIBUTES
File Organization: sequential
Record Format: fixed
Record Attributes: carriage-return
Maximum Record Size: 80
Longest Record: 80
Blocks Allocated: 117, Default Extend Size: 0
End-of-File VBN: 115, Offset: %X'0020'
File Monitoring: disabled
Global Buffer Count: 0
The analysis uncovered NO errors.
ANALYZE/RMS/CHECK CDSTP00FI00000146.;
|
| 3946.3 | | CANTH::WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Mon May 05 1997 09:58 | 22 |
| I would like to make sure I understand what was done. The COPY was
initiated on the 7.1 system? I ask because the trace looks like it was
analyzed on the 6.3 system (we accidentally shipped a bad ositrace.exe
image with 6.3 that would create the kind of trace file you have).
Could you please check to be sure where the trace was analyzed. If the
trace *was* analyzed on the 7.1 system, check SYS$SPECIFIC:[SYSEXE] for
an old version of ositrace.exe.
It doesn't make sense to me that the customer is using FTAM to copy
files between two OpenVMS systems, but...... Since the trace doesn't
indicate any problems (other than the fact that it just terminated),
and since the error message was slightly different with the second
test, we need to start looking elsewhere.
On the responder system, check the OSIF$RESPONDER.LOG for any errors.
Does this happen with all files, or only one particular file? Would it
be possible to get an OSI Transport trace to make sure we aren't having
a lower layer problem? Check the account that's being used on the
responder system to make sure that it has sufficient page file quota.
--Scott
|
| 3946.4 | By the way.. | CANTH::WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Mon May 05 1997 16:53 | 5 |
| While the information provided so far doesn't clearly point to an FTAM
problem, and we're not aware of any outstanding issues that match the
symptoms, you should go ahead an escalate this as an IPMT.
--Scott
|
| 3946.5 | | STP01::STPVNV::stp01::voinov | Vladimir Voinov, MCS Russia | Tue May 06 1997 06:46 | 30 |
| > I would like to make sure I understand what was done. The COPY was
> initiated on the 7.1 system?
Yes, the source is 7.1 system
> If the trace *was* analyzed on the 7.1 system, check SYS$SPECIFIC:[SYSEXE]
for
> an old version of ositrace.exe.
As I was told, there is no ositrace.exe in SYS$SPECIFIC:[SYSEXE].
They have found one in SYS$COMMON:[SYSEXE], dated 22-OCT-1996,
2145 blocks size.
The customer communicates with DANnet, Europian center for celllular
systems, that is why they are using FTAM. And it is quite difficult
to check the other side against log files and so on. DANnet people
say that no other of their clients have similar problems.
Another thing I get known is that there were problems like this
with DECNET 6.3, but all worked fine after enabling the trace
($ DEFINE OSAK_TRACE ON). After upgrading to 7.1 it doesn't help
anymore.
Also, only 7.1 produces the system error message
%SYSTEM-E-LEN_NOTPAGMULT, specified length is not a multiple of
CPU-specific pages
What does this message mean in FTAM context?
|
| 3946.6 | | CANTH::WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Tue May 06 1997 08:59 | 22 |
| Sigh..... We fixed that problem with ositrace once already.
You should never have needed to turn OSAK tracing on in order to get
FTAM to function; it would have been much better to report a problem
like that to engineering. Oh well.
The SYSTEM message, I think is bogus. FTAM doesn't internally generate
this, and I can't think of any system service that FTAM might call that
does generate it.
Without some additional information from the other side, it's going to
be difficult to track this down. In the absence of that information, I
would suggest that the next step would be to perform an OSI Transport
trace so that we can verify which side is initiating the disconnection.
If this is over an X.25 connection, you should also perform an X.25
trace, since if it's TP0 we might not be able to tell who initiated the
disconnect from the transport trace. And, if you haven't initiated an
IPMT, I would strongly encourage you to do so.
--Scott
|
| 3946.7 | | CANTH::WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Tue May 06 1997 09:16 | 8 |
| re the ositrace problem; please check sys$message to make sure that
the following two files exist, and that they only exist in SYS$COMMON
not old ones in SYS$SPECIFIC:
Directory SYS$COMMON:[SYSMSG]
OSIF$ASN1_MF.EXE;1 OSIF$FMSG_MF.EXE;1
|