| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3923.1 | Hello... | FORAT::PONS | | Tue Apr 08 1997 13:15 | 1 |
| Please anybody can help me???
|
| 3923.2 | Here's A Guess | TECMAN::SAUNDERS | John Saunders, DECdns Engineering, DTN 226-5173 | Tue Apr 08 1997 13:30 | 29 |
| I'll make a guess:
BLOCK NODE 0 EVENT DISPATCHER OUTBOUND STREAM local_stream -
SPECIFIC FILTER = ((node PALMES OSI Transport local NSAP), -
remote transport disconnection
I'd guess you need a right bracket. Try:
BLOCK NODE 0 EVENT DISPATCHER OUTBOUND STREAM local_stream -
SPECIFIC FILTER = ( -
(node PALMES -
OSI Transport -
LOCAL NSAP 49001CAA00040051732 -
Remote NSAP 49000008000601850521), -
Remote transport disconnection)
See if that works.
John Saunders
DECdns Engineering
P.S. This guess is brought to you by an Engineer who has only been
doing DECnet-Plus for three months now. Although he has learned how
to shut off "Unavailable user buffers" messages, that does not make
him an expert.
P.P.S. That's an interesting remote NSAP there. Am I seeing area zero
there?
|
| 3923.3 | Global Filter works too | CXO3W1::M_SHELDON | | Wed Apr 09 1997 00:01 | 17 |
| I was always more partial to global filters... they take care
of multiple instances and were shorter to type:
block e di out s * global filter = -
((osi transport, local nsap, remote nsap), remote trans disc)
According to the URL: http://www.pmg.com/text/oui_add.txt
the 08-00-06 OUI portion of the ethernet address encoded in the NSAP
was assigned to Siemens Nixdorf. The NSAP's not PhaseIV compatible,
but should be perfectly legal in the OSI world.
Mike Sheldon
CSC/CS Network Support
|
| 3923.4 | Thanks, after implemantation block works OK. | FORAT::PONS | | Wed Apr 09 1997 05:36 | 1 |
|
|
| 3923.5 | Glad It Works. NSAP Question? | TECMAN::SAUNDERS | John Saunders, DECdns Engineering, DTN 226-5173 | Wed Apr 09 1997 11:11 | 19 |
| I'm glad .0 is solved. Maybe I'm learning...
About that NSAP, though:
I thought 49 meant local use, binary encoding. I thought that meant that the
IDI was null, so that the rest of the NSAP is DSP. I thought that the
interpretation of the DSP in '49' cases was specified locally.
That being the case, and this NSAP being used to connect to DECnet-Plus nodes, I
thought that either the Siemens-Nixdorf node thinks its talking proper DECnet
and that it's in area 0, or else '0000' means something else to that node, in
which case, I'd expect interactions between them to be ... interesting.
Am I wrong about implementation-specific interpretation of the format of the DSP
field in the case of '49'?
John Saunders
DECdns Engineering
|
| 3923.6 | You're partly right | COMICS::WEIR | John Weir, UK Country Support | Mon Apr 14 1997 04:38 | 30 |
|
John,
>About that NSAP, though:
>
>I thought 49 meant local use, binary encoding. I thought that meant that the
>IDI was null, so that the rest of the NSAP is DSP. I thought that the
>interpretation of the DSP in '49' cases was specified locally.
Well, I think that's all OK, so far...
>That being the case, and this NSAP being used to connect to DECnet-Plus nodes, I
>thought that either the Siemens-Nixdorf node thinks its talking proper DECnet
>and that it's in area 0, or else '0000' means something else to that node, in
>which case, I'd expect interactions between them to be ... interesting.
I think that this is where you're jumping to invalid conclusions.
Almost certainly the Siemens-Nixdorf system is using OSI applications
over OSI Transport. This is not "proper" DECnet (at least in the sense
that it is not using DNA Session Control).
As long as you don't need RVR (Ph IV compatible) routers to route
the messages, there are not many restrictions on the NSAP values.
(With LOC_AREA = 0000, this is not PhIV compatible.)
Regards,
John
|