Abdullah, Since you haven't posted the working NCP definitions - or the relevant CIP definitions - I'm going to have to tease out of your descriptions what I can deduce about your SDLC line.
I expect it is a nonswitched line, GROUP DIAL=NO, and is SDLC, of course, LNCTL=SDLC, I'm familiar only with the outline of the "tricks" used with Cisco machines in order to support SDLC. One of these outline understandings is that the SDLC line is "terminated", as they say, on the Cisco machine and is made to appear as a token ring LLC2 connection to VTAM through and XCA node. Well I confirmed all the above with a little Googling, http://www.ccnu.com/tech/cisco_config/html/sample7.htm , for example, offers a "presidential" example. Because of the capability your modem has to change speed when it feels it needs to, I can deduce CLOCKNG=EXT. Probably such a relatively fast circuit is full duplex (in my experience, only old very low speed circuits are half-duplex). Since it's a 3174, it can operate with format 3 XIDs and so all the troublesome link station parameters such as MAXDATA can be left to be provided by the 3174 itself. Thus I can produce a sample definition as below. gpname GROUP DIAL=NO, LNCTL=SDLC, REPLYTO=1 linename LINE ADDRESS=(32,FULL), or whatever for the RLN CLOCKNG=EXT, DUPLEX=FULL, LSPRI=LINK, NEWSYNC=NO, NRZI=YES, PAUSE=(0.2,2.8), RETRIES=(15,0,0), ISTATUS=ACTIVE puname PU ADDR=C1, or whatever for the SDLC secondary address ANS=CONT, MAXOUT=20, MODULO=128, PUTYPE=2, XID=YES, ISTATUS=ACTIVE This gives me - and you - a template which I can use to try to figure out what may be missing in the CIP configuration. Since you have achieved some communication, the equivalent of parameters such as CLOCKNG, NRZI on the LINE statement and ADDR on the PU statement must be correct. Since the problem arises when the modem decides it needs to change speed, presumably in an attempt to recover its carrier - which it appears from the messages succeeds - I expect you are suffering from lost data. I can guess that sufficient frames are being lost over sufficient time for the equivalent of REPLYTO on the GROUP statement and RETRIES on the LINE statement to have been exceeded. So I decided to try to find the equivalents to these parameters on the web and I may have come up with a golden "hit" - not too difficult really. <g> It is the following: http://www.cisco.com/warp/public/697/dlswts6.pdf This is 13 pages under web page IBM Networking, Troubleshooting DLSw: SDLC, Document ID: 17566, Here I find that, in addition to the basic definitions found for router "reagan" on the earlier reference, which were simply interface Serial0 no ip address encapsulation sdlc no ip route-cache no keepalive clockrate 9600 sdlc role primary sdlc vmac 0110.2222.3300 sdlc address C4 sdlc xid C4 CE5000C4 sdlc partner 4000.7000.0001 C4 sdlc dlsw C4 the following which, as long as you understand what the NCP parameters do, can be seen to be Cisco equivalents of some important NCP parameters: REPLYTO = sdlc t1 <milliseconds> RETRIES first suboperand = sdlc n2 <retry-count> PAUSE = (approximately) sdlc poll-pause-timer <milliseconds> MAXOUT = sdlc k <window-size> What Cisco doesn't have, which NCP does and is something that might be very useful with this circuit where the modems like to change the speed, is the ability to pause in the middle of retry sequences. You may like to time how long it takes for the modems to resynchronise and then make sure that, if this time is x seconds, x is less than t1 times 1000 times n2. Clearly whatever you had specified for your NCP was suitable and it may have involved the second suboperand of the RETRIES operand. Your email address doesn't tell us where you are but I'm going to guess your name does and further guessing the geography may be relevant. About 25 years ago, I paid a visit to Riyadh. Part of my activity there was to interview some "network specialists" in the making. I was struck by the fact that they all seemed to have engineering degrees from American universities and they spent much of their time "balancing" modems. Obviously your problem reminded me of these interviews. Probably, even 25 years on, there are still some circuits of dubious quality out there - I fancy for no reason other than fancy - crossing the "Rub al Khali", which exercise more modern modems. <g> Before posting I checked the past posts and noticed your rate of problem incidents was once every 5 seconds which is very frequent. This could indicate a "retries" problem or it could indicate a symptom/solution I spotted in the Cisco guide which is a "duplex" mismatch. That's worth checking too, something I could have tackled if you had posted all the configuration information for which I asked. Chris Mason ----- Original Message ----- From: "Abdullah AlShaalan" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Sunday, 28 May, 2006 7:36 AM Subject: Re: INOP Received > What I saw regarding this problem is the following: > If the link, that connects remote 3174, drops from high speed to lower; the > serial interface of the router defining the link goes down then up > immediately. It may resynchronize with new speed. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
