| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 75.1 | OSIT$IVPINIT can be useful | BIKINI::DITE | PhaseV - Don't Worry! Be Happy... | Thu Aug 30 1990 19:25 | 23 |
| > I just come from the site where I've installed FTSIE, but the
> Siemens people over here seems to be totally unfamiliar with
> their products.
This is not unusual
> After giving them their host parameter (found on the conference)
> finally they said everithing was OK on their side, but I was
> getting TIMEOUT all the time.
>
> Unfortunatly the VOTS ivp requires a fixed TSAP so I cannot use
> with the Siemens even if it works in a loop-back mode.
>
Before trying anything with FTSIE, try using OSIT$IVPINIT with your IEEE-NAP
with their address. If they've given you their proper 802.2 address and have
set it up properly you should get their implementation of OSI Transport (BCAM -
Siemens component) to respond with a DR indicating that the TSAP
is not available. Use the VOTS trace and events to see what is happening
on a MAC and transport level.
Hope this helps.
John from a not so sunny DECville
|
| 75.2 | Remote system not accessible | CESARE::CATERINI | C6 B8 = formula del bagno | Fri Aug 31 1990 18:26 | 23 |
| Hi John,
at least you can see SOMETHING on the beaches outside the Palais!
I saw your reply only now coming back again from that customer.
I have tried the TRACE/VOTS START TRANSPORT/LIVE/FULL as well as
setting trace and /log for FTSIE copy, but doing only with FTSIE
because the OSIT$IVPINIT doesn't allow to specify the TSAP, only
the address.
I'm getting back the error:
"remote system not accessible" that's it, I suspect either the
FT-BS2000 is not running or their hw ethernet interface doesn't
work.
Do you know any command on the Siemens to Loop-back their stuff
both hw and sw? or is any way to broadcast to their hw and getting
back the result?
What's the sequence I should look for on the TRACE for the wrong
tsap running osit$ivpinit?
Thanks in advance.
Joe
P.S. I've forgotten, do you know where they keep their procs and
what to run on their side?
|
| 75.3 | Have you tried the following ? | BIKINI::DITE | PhaseV - Don't Worry! Be Happy... | Thu Sep 06 1990 13:58 | 66 |
| Ciao Joe,
sorry for this late reply, I've been travelleing back from Cannes the
slow way over the alps.
Now to your problem:
With FTSIE the message "Remote system not accessible" can be a little misleading
if you have not checked the underlying layers. You will basically always
get this message if FTSIE cannot build a connection to his partner. This does
necessarily mean that a transport connection is being initiated by your system.
That's why I tend to use the various tools available before trying to make
a connection using FTSIE.
Having installed and configured your system and assuming the system of your
partner is available:
1. Enable all events (VOTS and NCP)
2. use OSIT$IVPINIT for your system
3. use OSIT$IVPINIT for their system (i.e. use their 802.3 address)
I known that this procedure uses a TSAP calles VOTSIVP and that this
definitely won't be available on their system. This doesn't matter as
we're only trying to solicit a respone from their OSI Transport
implementation. Use TRACE to monitor any response.
If their system is correctly configured as far the 802.3 address and their
Transport implementation is concerned you should see a protocol exchange
on the Transport level something like this:
VAX SIEMENS
CR (TSAP=VOTSIVP)
--------> DR (reason = address unkown)
<-------
If you don't see this exchange then it's time to trace on the
MAC level to see if you get any type of response on the LAN.
If this reveals nothing go and see the Siemens system manager. Put the
ball in their court and ask them to initate a Transport connection.
Use TRACE to monitor their efforts.
Assuming that you have managed to validate with OSIT$IVPINIT that the 802.3
addresses are OK and that we receive a response from their Transport
implementation:
4. Using TRACE ascertain that VOTS is trying to build a Transport connection
after trying to submit a FTSIE COPY commando.
No trace would indicate that there is something the matter with the
parameters either in FTSIE or in VOTS. (transport classes, NAP name, etc)
If you see a trace of transport connection iniation you should get back an
error message with a lot more info.
If all this doesn't help give me a call on dtn 756-1386 (Thursday or Friday
the 6th/7th of September)
regards
john
P.S. Siemens has trace facilities. The problem is usually to find
somebody to activate it and to interpret it for you.
|
| 75.4 | NOW WORKS.... but some questions | CESARE::CATERINI | C6 B8 = formula del bagno | Fri Sep 07 1990 18:13 | 33 |
| Hi John,
thanks for the info's, I've managed finally to have everything
working yesterday and today.
Was a hw problem on their Ethernet interface plus a wrong version
of FT-BS2000 mixed together!
Now just a curiosity plus some questions:
1) How do you check the MAC level? with LANalyzer or our BRIDGE
sw I suppose.
2) Anyhow the qualifier /MAIL_NOTIFICATION doesn't work, why?
3) What's the exact formalism for the Siemens PASSWORD?
in example they have USER=PROVA,ACCOUNT=0,PASSWORD=C'PROVA'
but I couldn't figure out the exact syntax.
4) Why the synchr transfer is so slower compared to async?
5) Why the last TR (on the VAX only) spends more than a minute,
while instead all other types last only between 1-3/4 sec?
6) On the installation guide should be stated that the NAP must be
IEEE only while VOTS defaults it at IEEE_device.
7) It's possible that activating the trace on the Siemens will
allow the tranfer initiated on the vax which wasn't working until
then? We've rebooted both machines to reproduce it, but is still
working from then!
bye bye and thanks a lot again, I hope the weather is back to
normal now!
Joe
|
| 75.5 | | MUNTRA::SCHIMMEL | The Answer Is 42 | Mon Sep 10 1990 15:55 | 50 |
| Hi Joe,
2) Anyhow the qualifier /MAIL_NOTIFICATION doesn't work, why?
>> we had problems with /MAIL in former versions, but with V1.4 it should
>> work. Note: mail notification is only possible for the local VAX system.
3) What's the exact formalism for the Siemens PASSWORD?
in example they have USER=PROVA,ACCOUNT=0,PASSWORD=C'PROVA'
but I couldn't figure out the exact syntax.
>> try e.g. $FTSIE COPY local-file siemens-node"PROVA 0 'PROVA'"::remfile ...
>> or $FTSIE COPY local-file siemens-node"PROVA 0 C'PROVA'"::remfile ...
>> always use the same password syntax as if logging in to the SIEMENS system
>> -> beware of (single) quotes (except when a REAL decimal password is
>> used at SIEMENS side).
>> see note 22 for this problem (if you know GERMAN -- sorry!)
4) Why the synchr transfer is so slower compared to async?
>> I never made this experience comparing single transfers! Note the fact,
>> that in async mode several requests can be served simultaneously.
5) Why the last TR (on the VAX only) spends more than a minute,
while instead all other types last only between 1-3/4 sec?
>> what do you mean with "TR" ??
6) On the installation guide should be stated that the NAP must be
IEEE only while VOTS defaults it at IEEE_device.
>> this depends on the versions:
>> VMS4.7 / VOTS1.2 / FTSIE1.2 use IEEE
>> VMS5.n / VOTS2.0 / FTSIE1.3,1.4 use IEEE_device
7) It's possible that activating the trace on the Siemens will
allow the tranfer initiated on the vax which wasn't working until
then? We've rebooted both machines to reproduce it, but is still
working from then!
>> we had sometimes problems with "hanging" transfers in older versions.
>> no such problems with FTSIE V1.4B
Regards
Helmut
|
| 75.6 | MAC is a tracepoint | BIKINI::DITE | PhaseV - Don't Worry! Be Happy... | Thu Sep 13 1990 23:40 | 13 |
| Hi Joe,
sorry for the late reply as I can see you have all the right
answers from Helmut.
Re: 2) the MAC level is trace point you can use with the VOTS trace.
I hope the customer is happy now.
ciao
John
|
| 75.7 | thanks to all | CESARE::CATERINI | C6 B8 = formula del bagno | Thu Sep 27 1990 19:34 | 17 |
| Thanks guys,
the customer now work fine, but we still have the MAIL_ not
working in the sense we don't receive any mail.
About the password looks like the best way was to throw away the
password also because they don't use it on the Siemens side.
For the TR is the code in the TRACE/VOTS analize, when I'll get
the chance to go again to that customer I'll put on tape the trace
but if you look in any trace of transfer file you'll see the time
stamp of the last TR before closing the connection will last a
minute at least from the previous one, check the time between all
and you'll find it.
Bye for now and thanks again.
Joe
|
| 75.8 | MAIL: check NCP object characteristics | BIKINI::DITE | PhaseV - Don't Worry! Be Happy... | Fri Sep 28 1990 11:01 | 30 |
| Joe,
> the customer now work fine, but we still have the MAIL_ not
> working in the sense we don't receive any mail.
Have you checked the mail object characteristics in NCP (passw. etc)?
> For the TR is the code in the TRACE/VOTS analize, when I'll get
> the chance to go again to that customer I'll put on tape the trace
> but if you look in any trace of transfer file you'll see the time
> stamp of the last TR before closing the connection will last a
> minute at least from the previous one, check the time between all
> and you'll find it.
I still don't know what you mean with TR? Could it be DR?
Anyhow before I forget, if you go to the customer again take the latest
VOTS fix kit(March/May 1990) with you (available from your CSC). Check
the versions and link date of the OSIT$*.exe images on
sys$loadables_images: and see whether a fix kit has been installed. You
see this by the fact that you will find a file called votsfix020.txt on
sys$update:.
Run a few file copies and using mc osit$control check the values
in the TC database (dynamic) OSITCP> sh know TCs. If the parameter
"estimated delay" is continually high ie. a value of 000's rather than
0's or 00's I would suggest that you install the latest fix kit.
Regards
John
|