John, First the bad news: I'm being a bit critical - again. Now the good news: you've raised an important issue which needs to be covered. Now some even worse news - for me: chasing up this point, I discovered that my lectures, which were supposed to cover all important VTAM and NCP issues, had missed treating "initialization mode" (IM) as a separate topic worthy of having some research behind it.
What I'd been doing was treating IM as being the same as "normal disconnect mode" (NDM). One of the characteristics of NDM is that there are no limits to retrying sending the frame which initiates a connection. The NCP manuals are quite clear that there are retry limits in IM and that REPLYTO and RETRIES apply, at least in the case of SDLC. Other media can cause an NCP load module to be loaded from the disk and it may be said that, during this loading, they are also in IM and the retry limits as determined by the different media apply - in a quite complicated way for frame relay according to the manuals. Which replies are we talking about here to which a limit applies? Well, it is each reply during the load process. If the load is being performed over the link, there is a response to each load module block* and thus the timeout, the retry limit, and any resend delay, will apply to each of these responses. * I believe. There is nothing in the manual to confirm this and it's not a point made in my notes but I vaguely remember that this is the case - and it makes sense for flow control with a fairly basic bit of programming, the "Controller Load and Dump Program" (CLDP). You mentioned that the response time must cover loading of the NCP. That applies only when the NCP is being loaded from the disk. In this case there is one message to request loading and to provide the name of the load module and one response. The CLDP gets on with loading the NCP load module and says nothing, no matter how much it is pestered, until the loading is complete. (I was going to say that CLDP had first to be loaded but it makes sense that that happens when the "Set Initialization Mode" (SIM) frame appears and consistency demands that receiving the response to a SIM frame, a response sent only when the CLDP is loaded, is also covered by the retry limits. The reason "When you load a NCP over a link, the timeout has to be greater than the time it takes to load the NCP." is nearly correct is that the most lengthy operation without a response is this loading from disk (and maybe also storing to disk) so if you had added "from disk" you would have been entirely correct. However that is not the context of this thread. OK so how do you control these retry limits? Well, it's REPLYTO and RETRIES in combination, not just RETRIES. You need to apply the famous formula: Total time from the first try until the last retry times out = (T x (1 + P) x (1 + Q)) + (D x Q) where T = the REPLYTO value P = the first RETRIES value, the immediate retry count D = the second RETRIES value, the delay between retry sequences Q = the third RETRIES value, the number of retry sequences Now the question arises which you also tried to address, which RETRIES (and which REPLYTO)? I even have some support from the manual in saying that it is the GROUP, LINE (and PU) statements - in their hierarchical form rather than there being any influence from the SDLCST statements. The reason for this is that SDLCST statements and their stand-alone GROUP statements come into play only once contact has been made between the two link stations on the link, XID frames have been exchanged and the link stations have decided who is primary and who is secondary. The link stations (strictly it's only the secondary to which the "mode" applies) then enter "normal response mode" (NRM) with a "Set Normal Response Mode" (SNRM) frame or, to be complete, a "Set Normal Response Mode Extended" (SNRME) frame if modulo 128 rather than modulo 8 is agreed. You may have remembered that there is some trickery in the assigning of parameters during this configuration process. The parameter that is particularly tricky is MAXOUT. It's a long story but the conclusion is in the rule: "The MAXOUT specified on the SDLCST statement with MODE=PRI is never used." Thus the MAXOUT values that will apply are the value specified on the SDLCST statements with MODE=SEC when the link station is the secondary and the value specified on the PU statement subordinate to the hierarchical GROUP and LINE statements when the when the link station is the primary. Just to be complete about this matter of timeout control and retry limits, during normal operation, this configuration process rules. Thus, if the NCP contains the primary link station, the REPLYTO and RETRIES as specified by the SDLCST MODE=PRI will apply; if the NCP contains the secondary link station, the ACTIVTO as specified by the SDLCST MODE=SEC will apply. In the case of a link-attached NCP it's important to consider the extension to the configuration process which permits imposing the primary role on one link station and the secondary role on the other link station. There's a lot to be said for ensuring that the NCP that does the loading eventually contains the primary link station and the NCP which is loaded contains the secondary link station. Unfortunately this isn't always the case naturally since people habitually assign numbers from the bottom up. Thus if a link-attached NCP is to be added to the configuration, it tends to have the higher subarea number and, if the traditional configuring process is allowed to operate, it will contain the primary link station. The possibility to impose roles can deal with this unfortunate, in this instance, assigning habit. I did quite a lot of testing of disk support when it became available in order to be able to talk about it. In fact I made another mistake in assuming that REPLYTO=10 would apply for contact processing - which (the "left hand" would have told the "right hand" if it had been listening) operates with indefinite retries and a fixed 2.2 second timeout for NCP SDLC support. However taking REPLYTO=10 and the default RETRIES=(15,0,0), the formula above gives a total delay of 160 seconds. This appears always to have been sufficient time for whenever a disk access was needed. The manuals actually mention a delay of 3 minutes when the flow of the text demands. Thus, if you specify REPLYTO=10, RETRIES=(17,0,0) or RETRIES=17 exactly meets the 3 minutes suggested maximum estimate for disk activity. If there is some failure during the load process over the link you are going always to have to wait 3 minutes from the time of the failure in order to be informed that there has been a failure. It is not possible to have retry control for the disk access operation different from that for the individual blocks being sent over the link. In a way it's a shame I didn't have problems with my testing of disk support, or my very infrequent link loads, or I would have paid more attention to just exactly what happened. Chris Mason ----- Original Message ----- From: "John S. Giltner, Jr." <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 22 December, 2005 5:49 AM Subject: Re: Remote 3745 Definition > Ali Serdar Yakut wrote: > > Hi there, > > I do not know if this is the right list to post this, but I'm trying > > anything for help. > > I have got a very urgent situation. > > > > I am trying to have a configuration like - > > > > VTAM1 - NCP1 - NCP2 > > > > NCP1 is loaded in a channel attached 3745. NCP2 will be on a link attached > > 3745. > > In the NCP generation and loading guide the following is stated: > > > > > > <Snip> > > > When you activate a remote linkstation there is a timeout waiting for > the remote station to reply, this is specified by the RETRIES parameter. > When you load a NCP over a link, the timeout has to be greater than > the time it takes to load the NCP. > > Now, what I can't remember is where the RETRIES parameter used from. > There is one specified on the PU defintion and on the SDLCST macros. > Now the hazy part. One PU is the primary (IIRC the PU with the higher > number SA) and one PU is the secondary. The primary PU will use the > RETRIES on the PU statment and the secondary PU will use the RETRIES > from the SDLCST macro defined on its PU statment. > > Now you don't want to make this too high, as this is also the timeout > value for noticing that the remote NCP has died or gone away. So if you > set RETRIES so that it takes 15 minutes, the remote NCP could be down > for 15 minutes before the PU go INOP. ---------------------------------------------------------------------- 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
