[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEC X.25 for OpenVMS AXP |
|
| Moderator: | OZROCK::MUGGERIDGE |
|
| Created: | Mon Jan 18 1993 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 524 |
| Total number of notes: | 2218 |
494.0. "What would three restarts on a PVC mean to x.25?" by CX3PST::NOTAMI::A_ANDERSON (CX03 2/H13 NSU/VAX MacGhille Aindrais) Wed Jan 29 1997 07:06
Hello All,
I have a customer with an Alpha running open VMS 7.0 DECnet osi 7.0 and X.25 1.1
He has an application that uses PVC and a DEMSA running X25 router 2000 V1.1 BL7p
He is testing to see how his application recovers from failure conditions. To do this he isdropping the DTE. In the
level 2 trace we see the DTE recover and three restarts are received. His application gets two pathlost then after a 50
second pause he gets the third. I cannot see in the trace where the 50 second pause comes from. Also the
PVC in question is on channel 8. After the DTE recovers the first reset we receive is
on channel 8 which goes unanswered. The reset on the other PVC's get confirmed. After approx 3 minutes we receive
another reset on channel 8
Some of the Cause and Diagnstic codes are not in the RedBook so I have asked the custoemr to talk to the people who
maintain his X.25 switch for a explanation of what those codes are. The restart with a C=1 D=11 may be trying to tell us
something. Any Ideas on this?
The third Pathlost he receives confuses his application and it cannot do any I/O. He never sees the reset. Any qio he
performs never gets sent, the return status is good. If he gets a failure condition where he receives only two pathlost
his application recovers as expected.
Is there something about the number of restarts received? Perhaps an odd number means we are down while an Even number
means we have recovered? There does not appear to be any way to tell if a restart was received because the DTE went down
or because DTE came up. So I am guessing that one RESET means the DTE went down the SECOND restart means the DTE came
back up. So would a THIRD restart indicate the DTE went down again??
Running a X25 gap trace on the DEMSA I do not see the reset on channel 8 going out (Any ideas on what it will actually
look like, I may be missing it.)
The customer says that when he gets the pathlost he does a IO$_NETCONTROL with a PSI$K_RESTART and that the return status
on this qio is a 1. He modified his code to dump the first three bytes of the IOSB and receives the following on the
three IO$_NETCONTROL qio's
1st qio 1 20 5690
2nd qio 1 20 512
3rd qio 1 20 512
As far as I can tell the second and third byte is meaningless on a IO$_NETCONTROL, is this still correct?
Level two trace on the DEMSA
14:50:14.44|R-> | 2|X25-91P3 |Data |00000001| 01| C P DISC |
14:50:14.45| <-T| 2|X25-91P3 |Data |00000001| 01| R F UA |
14:50:14.45| <-T| 2|X25-91P3 |Data |00000001| 01| C P DISC |
14:50:14.55|R-> | 2|X25-91P3 |Data |00000001| 01| R F DM |
14:50:14.55| <-T| 2|X25-91P3 |Data |00000001| 01| C P SABM |
14:50:14.62|R-> | 2|X25-91P3 |Data |00000001| 01| R F UA |
14:50:14.63|R-> | 7|X25-91P3 |Data |00000001| 01| C I 0/0|000 RSTRT C=07 D=07 | C=7 Net
operational
14:50:14.63| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 1/ | D=7 ??? not in
redbook
14:50:14.64| <-T| 5|X25-91P3 |Data |00000000| 01| C I 1/0 |000 RSTRC |
14:50:14.68|R-> | 7|X25-91P3 |Data |00000001| 01| C I 0/1|000 RSTRT C=07 D=00 | C=7 network
operational
14:50:14.68| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 2/ | D=0 no more data
14:50:14.70| <-T| 5|X25-91P3 |Data |00000000| 01| C I 2/1 |000 RSTRC |
14:50:14.81|R-> | 7|X25-91P3 |Data |00000001| 01| C I 2/2|000 RSTRT C=01 D=11 | C=1 ??? not in
redbook
14:50:14.81| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 3/ | D=11 Packet type
invalid
14:50:14.82| <-T| 5|X25-91P3 |Data |00000000| 01| C I 3/2 |000 RSTRC for state
R1 packet
14:50:15.38|R-> | 2|X25-90P3 |Data |00000001| 01| C P RR 7/ | level ready
14:50:15.38| <-T| 2|X25-90P3 |Data |00000001| 01| R F RR 7/ |
14:50:15.41|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 3/ |
14:50:18.85|R-> | 2|X25-91P3 |Data |00000001| 01| C P RR 3/ |
14:50:18.85| <-T| 2|X25-91P3 |Data |00000001| 01| R F RR 3/ |
14:50:19.38|R-> | 2|X25-90P3 |Data |00000001| 01| C P RR 7/ |
14:50:19.38| <-T| 2|X25-90P3 |Data |00000001| 01| R F RR 7/ |
14:50:20.35|R-> | 7|X25-91P3 |Data |00000001| 01| C I 3/3|008 RST C=09 D=00 |
14:50:20.35| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 4/ |
14:50:20.87|R-> | 7|X25-91P3 |Data |00000001| 01| C I 3/4|00D RST C=09 D=00 |
14:50:20.87| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 5/ |
14:50:20.88| <-T| 5|X25-91P3 |Data |00000000| 01| C I 5/3 |00D RSTC |
14:50:21.04|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 4/ |
14:50:21.28|R-> | 7|X25-91P3 |Data |00000001| 01| C I 4/5|001 RST C=09 D=00 |
14:50:21.28| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 6/ |
14:50:21.28| <-T| 5|X25-91P3 |Data |00000000| 01| C I 6/4 |001 RSTC |
14:50:21.45|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 5/ |
14:50:22.08|R-> | 7|X25-91P3 |Data |00000001| 01| C I 5/6|012 RST C=09 D=00 |
14:50:22.08| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 7/ |
14:50:22.08| <-T| 5|X25-91P3 |Data |00000000| 01| C I 7/5 |012 RSTC |
14:50:22.24|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 6/ |
14:50:22.33|R-> | 7|X25-91P3 |Data |00000001| 01| C I 6/7|028 RST C=09 D=00 |
14:50:22.33| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 0/ |
14:50:22.33| <-T| 5|X25-91P3 |Data |00000000| 01| C I 0/6 |028 RSTC |
14:50:22.55|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 7/ |
14:50:22.60|R-> | 7|X25-91P3 |Data |00000001| 01| C I 7/0|013 RST C=09 D=00 |
14:50:22.60| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 1/ |
14:50:22.61| <-T| 5|X25-91P3 |Data |00000000| 01| C I 1/7 |013 RSTC |
14:50:22.84|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 0/ |
14:50:23.45|R-> | 2|X25-90P3 |Data |00000001| 01| C P RR 7/ |
14:50:23.45| <-T| 2|X25-90P3 |Data |00000001| 01| R F RR 7/ |
14:50:26.66|R-> | 2|X25-91P3 |Data |00000001| 01| C P RR 0/ |
14:50:26.67| <-T| 2|X25-91P3 |Data |00000001| 01| R F RR 1/ |
14:50:27.52|R-> | 2|X25-90P3 |Data |00000001| 01| C P RR 7/ |
14:50:27.52| <-T| 2|X25-90P3 |Data |00000001| 01| R F RR 7/ |
14:50:27.52| <-T| 2|X25-90P3 |Data |00000001| 01| R F RR 7/ |
14:53:11.58|R-> | 2|X25-90P3 |Data |00000001| 01| C P RR 7/ |
14:53:11.59| <-T| 2|X25-90P3 |Data |00000001| 01| R F RR 7/ |
14:53:14.02|R-> | 7|X25-91P3 |Data |00000001| 01| C I 0/1|008 RST C=05 D=33 |C=5 local
procedure error
14:53:14.02| <-T| 2|X25-91P3 |Data |00000001| 01| R RR 2/ | D=33 Timer
expired for
14:53:14.02| <-T| 5|X25-91P3 |Data |00000000| 01| C I 2/0 |008 RSTC | reset
indication
14:53:14.21|R-> | 2|X25-91P3 |Data |00000001| 01| R RR 1/ |
This is an article written years ago that we have been sending to customers
who have questions on X.25 progrraming for PVC's I believe its still accurate, and
this customer says he is following the recomendations in this article. If this is
info no longer accurate any comments would be welcome.
[VAX/P.S.I.] Programming a PVC
Any party granted access to the following copyrighted information
(protected under Federal Copyright Laws), pursuant to a duly executed
Digital Service Agreement may, under the terms of such agreement copy
all or selected portions of this information for internal use and
distribution only. No other copying or distribution for any other
purpose is authorized.
Copyright (c) Digital Equipment Corporation 1990. All rights reserved
LAYERED PRODUCT: VAX P.S.I. V4.X OP/SYS: VMS V5.X
SOURCE: Digital Customer Support Center
SUBJECT:
Programming to a PVC (Permanent Virtual Circuit).
DESCRIPTION:
This article explains how Digitals implementation of PVC's works in
reference to handshaking and expected mailbox messages.
Unlike a SVC, there are only two ways to determine whether or not a
PVC is functioning properly: create a DLM over the PVC, or send data
back and forth across the PVC via a program. The proper method of
handshaking which should be performed across a PVC is as follows.
1. Your program should $ASSIGN a channel to NWA0 or NVA0 then issue a
$QIO (IO$_ACCESS) with the specified PVC name in the PSI$C_NCB_PVCNAM
field in the NCB.
2. After you have accessed the PVC on both the remote and local DTE's
the slave program should have a $QIO (IO$_READVBLK) associated with a
mailbox waiting for an incoming message. The master program running on
the other DTE does a $QIO (IO$_NETCONTROL) P4=PSI$K_RESET. This will
send a level III reset out the PVC channel to reset the PVC to it's
initial condition and discard all pending messages. This also notifies
the remote DTE you wish to communicate.
3. The slave application should parse the mailbox to determine what the
MSGTYPE field is. If the MSGTYPE is a MGS$_RESET the slave application
should confirm that with a RESET confirmation.
NOTE:
When dealing with PVC's there are some types of mailbox messages to be
concerned with: MSG$_RESET which indicates a level III reset was
received, MSG$_PATHLOST which indicates a level II line restart was
received, MSG$_DISCON indicates the DECnet logical link to the
Multi-host node has been lost, and MSG$_INTMSG indicates an interrupt
message.
MSG$_PATHLOST in the MSGTYPE field of the mailbox or a SS$_MEDOFL in the
IOSB indicates that the PVC has been restarted. There is no additional
mailbox information provided. The restarting of a PVC can be caused by
the PSDN having a problem or by VAX P.S.I. during circuit initialization.
This makes it very hard to determine whether the circuit is coming up or
going down.
The reason for a MSG$_RESET in the MSGTYPE field of the mailbox is
indicated by bytes 1,2,3 in the mailbox info field. A reset can be
initiated by the PSDN, VAX P.S.I., or an application.
Byte 1 = Diagnostic Code
Byte 2 = Cause Code
Byte 3 = Reason for reset
Byte 3 reset reasons
PSI$_L3_NETWRK Initiated by the PSDN
PSI$_L3_NETERR PSDN protocol error
PSI$_L3_LNKDWN Link down
PSI$_L3_LNKUP Link up
PSI$_L3_LNKRR Link restart
PSI$_L3_LOCMGT Network management function
NOTE:
Depending on whether or not you are going through a PSDN or depending
on how closely the PSDN you are going through abides by the CCITT X.25
recommendations, determines the validity of the value in the mailbox
info field for a MSG$_RESET.
4. The master application should then get a SS$_NORMAL in it's IOSB
indicating that the RESET was acknowledged and the slave application
should also get a SS$_NORMAL in it's IOSB indicating it has confirmed
the RESET.
NOTE:
Receipt of a SS$_NORMAL in the IOSB does not indicate that the remote
DTE received the reset. If the PVC is functioning properly and the
remote PVC channel is not assigned to any application then the remote
system will send a reset confirming receipt of a reset. Additionally,
there could be network congestion when trying to send the
the resets which would either prevent the initial reset from being
delivered or the receipt of the reset confirmation. Thus, if after
a user determined time period the initial reset is not acknowledged
another reset should be issued. Depending upon the max. reset parameter
on the DTE determines how many times VAX P.S.I. will resend your reset
without you issuing a new IO$_netcontrol reset.
5. If no reset confirmation is received, this most likely means that
the PVC circuit is not functioning properly. If the PVC circuit is
down your QIO will sit there indefinitely. This is why the periodic
reissuing of a reset by the master application when there is no reset
confirmation is recommended. To verify that the reset confirmation
came from the remote DTE a handshaking scheme should be employed
between the two DTE's prior to transmission of data.
6. At this time normal communication can take place.
7. At all times during normal communication, both the master and slave
applications should be checking the status of the mailbox. If a
MSG$_PATHLOST is received confirm the message with a $QIO
(IO$_NETCONTROL) with P4 = PSI$K_RESTART. Then your application
should resync according to steps 2-5 of this procedure prior to
resuming normal data communications.
If a MSG$_RESET is received in the mailbox then the two applications
should resynchronize per steps 2-5.
If a MSG$_DISCON is received in the mailbox then to reconnect to the
PVC use a $QIO (IO_DEACCESS), and then a $QIO (IO$_ACCESS) to
reconnect to the PVC. Then resynchronize the two applications per
steps 2-5.
8. Tear down of the link is the same as a normal task to task, $QIO
(IO$_DEACESS) and $DASSGN.
Thanks
Alan S. Anderson
Network Support CSC CS
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|