| Title: | Siemens Connectivity |
| Notice: | FTSIE Contact is Michael Eisenhut @MUC 865-1487 |
| Moderator: | UFHIS::MEISENHU |
| Created: | Tue Aug 30 1988 |
| Last Modified: | Mon Feb 19 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 195 |
| Total number of notes: | 512 |
My customer uses FTSIE 1.4 to transfer data from SIemens to VAX
(FTSIE$CMD is 1.4-01)
This works fine as long as the files are small. If he tries however to
transfer files of about 60000 blocks, the VAX doesn't write to disk,
but buffered IO and CPU time is increasing. It also stops the transfer
after some time with different error messages, e.g.
- remote file inconsistant, -disconnected from remote system, -file
accessed on channel
This happens only, when he starts the transfer at the VMS side; if he
sends from the SIemens side, the transfer seems to be ok. (he compared
the first and the last record of the file with the original one)
Before I recommend to upgrade to FTSIE 1.4-E or 2.0 I wanted to know
if this is a known error or what I could do to analyze it further.
I have asked him to get a trace with "osi_transport port *", but didn't
see anything abnormal (DTs with EOT, AK, and DR with normal disconnect
initiated by session, DC)
I have compared it with a successful transfer trace, but did not see
anything significant. I have the traces available, if anybody is
interested.
Any hints are very welcome
thanks in advance
eva
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 165.1 | Upgrade to V1.4E / V2.0 | BIKINI::DITE | DECnet/OSI makes ~~~~ OK! | Tue Aug 03 1993 13:48 | 12 |
Hi Eva, your going back a long long time.... ;-) The SSB Version V1.4 is known to contain many problems - not all have been documented. Therefore I would recommend that you upgrade to V1.4E or better still get V2.0. regards John | |||||
| 165.2 | 1.4e did not help | MUNICH::SCHALLER | Eva Schaller *DSC* 895-6146 | Thu Aug 05 1993 11:24 | 20 |
John,
we have upgraded to 1.4E, but it changed nothing.
Small files (up to 10000 around) work fine; larger ones (60000 and
200000 blocks) always fail as described in .0
All transfered files are created by the same application, so the file
structure shouldn't matter. Another indication is the fact, that it
works, if the transfer is initiated by the Siemens system.
BTW, the file is SEQ, VAR up to 4000 bytes.
Is it possible, that the buffering is made different dependent on
the initiating side? Maybe we have to increase some buffers/params
(VOTS; FTSIE)
Any further suggestions?
thanks eva
the
| |||||
| 165.3 | Some more suggestions.... | BIKINI::DITE | DECnet/OSI makes ~~~~ OK! | Fri Aug 06 1993 14:28 | 46 |
Eva,
.2> we have upgraded to 1.4E, but it changed nothing.
.2> Small files (up to 10000 around) work fine; larger ones (60000 and
.2> 200000 blocks) always fail as described in .0
.0> It stops the transfer after some time with different error messages, e.g.
.0> - remote file inconsistant, -disconnected from remote system, -file
.0> accessed on channel>
From the last two messages here it could well be a case that the remote system
disconnected the transport link. This one would have to investigate further
using the trace files.
.2> All transfered files are created by the same application, so the file
.2> structure shouldn't matter. Another indication is the fact, that it
.2> works, if the transfer is initiated by the Siemens system.
.2> BTW, the file is SEQ, VAR up to 4000 bytes.
More important, what are the Siemens file charactersistics (type, record length
etc,) that the VAX is trying to fetch.
Remember that there is a record size restriction of 4000 octets using
FORMAT=TEXT or =BINARY
.2> Is it possible, that the buffering is made different dependent on
.2> the initiating side? Maybe we have to increase some buffers/params
.2> (VOTS; FTSIE)
.2> Any further suggestions?
System Parameter Minimum System Requirements
GBLPAGES 1500
GBLSECTIONS 10
MAXBUF 4096
INTSTKPAGES 3
Ensure that you run your tests in synchronous mode. You'll then be able to see
exactly whether the break in transmission was caused by FTSIE or SNI?
John
PS> I'll be out of the office till the 02/09/1993.
If you have to escalate this problem please remember to give us the details
of the DCAM and the FT-BS2000 version.
| |||||