I'm obliged to apologise for not appending previous posts. If I did so, I would blow the list limit of 1000 lines. I'm not even sure this will work. It might actually be handy if this page showed how many lines so that I wouldn't have to waste time reposting!!!
George I hope your work with the z/OS Communication Server (CS) "TN3270E" server is still in a test phase since I don't want you making changes in a production environment. This is first of all a response to your last point regarding the possible use of the IBM-DYNAMIC code. It makes sense to specify this only after you have distributed software to your TN3270 users' PCs which causes the Attachmate emulator to specify IBM-DYNAMIC as the TN3270E negotiation DEVICE-TYPE code. If you are unclear what this means, take a look at the 13.4 Examples section in RFC 2355, for example: http://www.faqs.org/rfcs/rfc2355.html As to the TELNETDEVICE statement which is actually relevant to your users, you can determine what this is by using the following command and looking for the value of "DEVICETYPE:" DISPLAY TCPIP,tnserv,CONN,CONN=nnn where tnserv is the name of your TN3270E procedure - which I see is TN3270E, logically enough! - and nnn is the number associated with one of the active connections. This is really significant only when you want to specify a non-default value for the name of the mode table entry. However, you always show that you are on top of your definitions when you specify relevant defaults. As I said before, if the code you see from the command is IBM-3278-3-E, the TELNETDEVICE command which associates that code with the name of the mode table entry which the "TN3270E" server will use for the concatenated SNA session is as follows: TELNETDEVICE IBM-3278-3-E ,SNX32703 The effect of the comma is to ensure that the mode table entry name is in the *second* positional parameter position and is hence the one used by a TN3270 connection where the use of the TN3270E protocols has been agreed - just like all but the first example in section 13.4 in RFC 2355. The effect of *not* having the comma is to cause the named mode table entry to be used only when the use of TN3270 protocols have been agreed - as in the first example in section 13.4. Since you are always using TN3270E protocols, you will never use those mode table entries. It was at this point I decided that you needed the "tutorial" on session setup where the z/OS Communications Server "TN3270E" server was involved. If you haven't read through that post yet, now is the time. - Note that the customisation I have been talking about assumes that all your users are configured identically as far as defining the TN3270E DEVICE-TYPE code is concerned. However, even if some are different and happen to specify other codes, they are still very likely to work since a suitable mode table entry from the IBM-supplied table is specified by default. Now that - I hope - you understand the TN3270 session setup process including the role of the TELNETDEVICE statement, I hope you understand how you can best use the TELNETDEVICE statement - if indeed you need to specify any TELNETDEVICE statements at all. - Now let's look at the whole of your post. > I didn't make the original changes to the system in support of this change. Perhaps I should be discussing these matters with whomever did. > ... in the server (as you call it). I believe I'm using the word "server" only as in the "client"-"server" context - except where I am referring to Communications Server perhaps. Regarding the APPL major node: > DLOGMOD=MTQRYPC Since none of your TELNETDEVICE statements - nor any of the default TELNETDEVICE statements - specifies "NONE" as a pseudo-mode table entry name, you will never use the DLOGMOD operand value as a mode table entry name. I hope that is clear from the "tutorial". >From the description of the TELNETDEVICE statement: <quote> The LOGMODE name NONE prevents Telnet from specifying a LOGMODE request with the REQSESS. </quote> Yes, I agree that the manual authors do not actually say that only when "NONE" is specified does the value of the DLOGMOD operand have a role to play - assuming that they actually understand the VTAM API which cannot be taken for granted! - but that is what the consequences are. > MODETAB=PBSBMODE There is no evidence that you are using mode table entries other than those to be found in the IBM-supplied table ISTINCLM. > USSTAB=VTMUSS0N The USSTAB operand specified on an APPL statement applies only to the processing of operator commands and messages when the APPL statement works with the "programmed operator" API. It would appear that VTAM development have "missed a trick" here if they do not flag this as an error when AUTH=SPO or AUTH=PPO are not also specified. >From the description of the APPL statement USSTAB operand: <quote> USSTAB applies only to a program operator application program (AUTH=PPO or AUTH=SPO). It is ignored if you code it for an application program that is not a program operator. </quote> > AUTH=NVPACE Since the APPL statement defined for use by the "TN3270E" server will *always* be the secondary LU in SNA sessions, the AUTH=VPACE|NVPACE suboperand is irrelevant. >From the description of the APPL statement AUTH operand VPACE|NVPACE suboperand: <quote> Determines whether this application program is subject to the VPACING specifications of SLUs with which the program is in session. Coding NVPACE is the same as coding VPACING=0 in the LU definition statements for all of the SLUs with which the application program is in session. </quote> Just to be clear, if the session partners are SLUs (secondary LUs), then the APPL statement covered by the suboperand must be the *primary* LU and, in the case of your APPL statements, they are not primary LUs. Otherwise EAS=1 is good since it conserves storage. PARSESS=NO is default so is not really necessary. In the past I have recommended SESSLIM=YES but there's a new function, SHAREACB, in V1R12 which I suspect might require SESSLIM=NO, the default, if the new function is used. Thus your GROUP statement for the APPL statements reduces to having just EAS=1 as an operand. In the past I may have added SESSLIM=YES but, in order to prepare for the V1R12 enhancement, maybe you had better leave it to default to SESSLIM=NO - or - better still - if you should implement the SHAREACB function when you start to use V1R12, just to show you are on top of the specifications upon which you rely, you should then actually specify SESSLIM=NO. In checking previous releases of the Communications Server IP product, I found that the proposed APPL statement (in "TCP/IP for MVS" V3R2) was as follows:[1] TCPIMS33 APPL AUTH=NVPACE,EAS=1,PARSESS=NO,MODETAB=ISTINCLM,SESSLIM=YES I don't have a system to hand in which I can find the IVPLU member of SEZAINST which, in effect, has replaced actually providing a recommended APPL statement in the "configuration" manuals. However I happen to have what I believe is a copy of the data set members from a few years ago. The IVPLU member is the following - removing unnecessary comments which contain the date 1999: <member> * APPL Major node for TN3270(E) server LUs. * * This node defines a model application name of TCPABC* * This node covers TCPABC00 to TCPABC99 as defined in * the TCPIP PROFILE stmt. DEFAULTLUS TCPABC00..TCPABC99 * TCPABC VBUILD TYPE=APPL * TCPABC* APPL AUTH=NVPACE,EAS=1,PARSESS=NO,MODETAB=ISTINCLM,SESSLIM=YES MODSRCH=FIRST </member> If this represents what the CS IP developers consider a valid example, then they need to go back to VTAM school! As explained above, EAS=1 and SESSLIM=YES (with a question mark over V1R12) are sensible. MODETAB=ISTINCLM is really pointless and PARSESS=NO is not really worth specifying since the "TN3270E" server logic will never try to create parallel sessions. AUTH=NVPACE is arrant nonsense! MODSRCH=FIRST is interesting. MODSRCH=NEVER is the default and this implies that model APPL statements will not be used when the application uses the INQUIRE APPSTAT/STATUS call over the VTAM API. However you don't specify MODSRCH=FIRST and you seem to be able to set up session quite happily with your model APPL statements. The conclusion is that whoever put that IVPLU member together got a hint possibly from reading about the TSO use of model APPL statements or seeing sample model APPL statements for TSO use where MODSRCH=FIRST is required and - sort-of to be on the safe side - decided that maybe MODSRCH=FIRST was a general requirement for the serious use of model APPL statements and so added/left MODSRCH=FIRST to/in his or her sample model APPL statement without really having the first clue what he or she was doing! What these samples demonstrate is that you have been given rotten advice over how a TN3270 server VTAM APPL statement should be specified from the highest - if quite uninformed - source, namely the product "configuration" manuals. This illustrates that even now that the two former products have been "merged" as the Communications Server product, no effort has been made to improve the standard of the advice concerning the "sister" product. Thus, as always, any advice in product manuals about any other product is never to be trusted, a maxim I have found to be true time and time again even within IBM. But - the fact that this example has only one asterisk shows us that your APPL statements - I guess - work but may not be precisely what you had in mind when you coded them. Here's the relevant text from the description of the "name" of an APPL statement in the CS SNA Resource Definition Reference manual: <quote> name must follow the rules for naming application programs as described in the z/OS Communications Server: SNA Network Implementation Guide and can include the following wildcard characters: Asterisk (*) Represents 0 or more unspecified characters. An asterisk can be used as the second to eighth character. Question mark (?) Represents a single unspecified character. A question mark can be used as the first to eighth character. </quote> In > TELNI*** APPL > TELNE*** APPL you have three asterisks whereas one is sufficient. If you really wanted the match to be on say "TELNE" with precisely three additional characters, you should specify three question marks: TELNE??? - Turning now to what appears to be that part of your PROFILE data set covering essentially interface and routing definitions, the following points can be made: > ARPAGE 20 >From the CS IP Configuration Reference manual: <quote> ARPAGE statement ... The ARPAGE statement only applies to LAN channel station (LCS) devices. </quote> Based on the HOME statement, you appear to have provided all the interface definitions and none of them are for "LCS devices" such as a 3172 or an OSA configured to appear to be a 3172. Thus ARPAGE is irrelevant. > IPCONFIG ... SOURCEVIPA SOURCEVIPA as a parameter of the IPCONFIG statement is - almost - an obsolete parameter. In case you haven't worked through this matter before, you should look through the following section in the CS IP Configuration Guide to be sure you are using the most suitable technique for controlling the source IP address in the IP packets that this IP node is sending: Chapter 5. TCP/IP Customization - Configuring PROFILE.TCPIP -- Setting up TCP/IP operating characteristics in PROFILE.TCPIP --- Source IP address selection You will see that the IPCONFIG statement SOURCEVIPA technique is the seventh out of eight ways to set a source IP address and is just about the messiest - although tidier if you switch to using INTERFACE statements for your OSA interface definitions. > DEVICE OSA0402 MPCIPA NONROUTER AUTORESTART > LINK OSA0402LNK IPAQGNET OSA0402 VLANID 25 I recommend you explore using the VMAC parameter. The mechanism associated with the VMAC parameter ensures that the OSA feature port behaves in a manner considerably superior to that of the original OSA QDIO design. So much so that it is really how it should have been designed in the first place and the original technique should be forgotten as a bad dream. If you do decide to upgrade to using the QDIO OSA in, as it were, "VMAC mode", you will note that you will need to use the ROUTELCL parameter to replace the NONROUTER parameter.[2] I can't be sure but I would expect there will be a tendency to restrict future enhancements to OSA QDIO only to "VMAC mode" - and, incidentally, the point about future enhancements applies also to defining OSA QDIO using an INTERFACE statement rather than the DEVICE/LINK/HOME entry/BSDROUTINGPARMS entry statement combination. Having raised that point, I'd better help by showing how your existing statements look when converted to INTERFACE statements: <quote> INTERFACE — IPAQENET OSA-Express QDIO interfaces statement Use the INTERFACE statement to specify an OSA-Express QDIO Ethernet interface for IPv4. </quote> INTERFACE OSA0402 DEFINE IPAQENET PORTNAME OSA0402 IPADDR 10.254.76.31/8 SOURCEVIPAINTERFACE VIPA01L VLANID 25 VMAC ROUTELCL Notes: a. I have chosen the name of the DEVICE statement for the INTERFACE statement in order to be compatible with the name used in the existing START statement. b. The SOURCEVIPAINTERFACE is needed since this definition doesn't depend on the HOME statement list for the purposes of selecting the source IP address of a VIPA definition. If you decide on another way to specify the source IP address, this may not be needed. c. There are later comments on the subnet mask. This really should be something much more sensible than /8 such as /26 in order to handle your already chosen addresses but, with different addresses, it could be as "narrow" as /28. d. The mechanism associated with the AUTORESTART parameter of the DEVICE statement is assumed always to apply to an interface defined with an INTERFACE statement.[3] e. MTU is a rather large topic and the MTU parameter could be specified with a value but the assumed default value is almost certainly acceptable as input to the logic which selects the MTU. See "Maximum transmission unit considerations" in Chapter 2, "IP configuration overview" in the CS IP Configuration Guide manual - and ask yourself whether or not PATHMTUDISCOVERY might be a handy function to enable in your IP network - given the imprimatur that it is standard with IPv6. > TRANSLATE I can't see what this statement - with or without any parameters - is doing in your definitions. > BEGINROUTES > route 10.00.00.00/08 10.254.76.01 OSA0402LNK MTU 1492 > route 10.00.00.00/08 10.254.76.01 OSA0602LNK MTU 1492 > ... > ENDROUTES Rather oddly, you have chosen to assign an address range of in excess of 16 million IP addresses from your intranet solely to the LAN - a VLAN (virtual LAN) superimposed on the real LAN to boot! - to which your OSA feature ports and at least the adjacent router connect. It is much more normal to assign a subnet mask which reflects the likely maximum number of interfaces which will ever connect to the (V)LAN. Thus, if the address range needs to allow for a maximum of 14 interfaces, your subnet mask would be /28, if 30, /27, if 62, /26 and so on. Unfortunately, you need to make this design choice *before* assigning actual addresses to interfaces. The addresses you have chosen will all fit into an address range for your VLAN only if the address range is defined by a subnet mask of /26 - or a more wastefully "generous" subnet mask. I appreciate that when using RFC 1918 addresses within an int*ra*net, you can generally afford to be wasteful with no bad effects. However, a tidy approach is always to be preferred IMNSHO and assigning in excess of 16 million to a VLAN which is likely to have just 10 or 20 or 30 interfaces attached to it is quite the opposite of a tidy approach. I hope the subnet mask did not get set at 8 because it was thought that subnet mask value was necessarily associated with an IP address with "10" as the first octet value. That "0" in front of the "8" is very suspicious! Since you are not using dynamic routing, it may be that you are relying on the "gratuitous ARP" support in the OSA feature logic when configured as QDIO in order that your adjacent router on the VLAN can find your VIPA. In order to be sure that this is happening you should use the NETSTAT DEVLINKS command and expect to see something like the following: EZZ2826I IPv4 LAN Group Summary EZZ2827I LanGroup: 00001 EZZ2828I LnkName LnkStatus ArpOwner VipaOwner EZZ2829I ------- --------- -------- --------- EZZ2771I OSA0402LNK Active OSA0402LNK Yes EZZ2771I OSA0602LNK Active OSA0602LNK No If, say, OSA0402LNK became inactive, then you should see something like the following: EZZ2826I IPv4 LAN Group Summary EZZ2827I LanGroup: 00001 EZZ2828I LnkName LnkStatus ArpOwner VipaOwner EZZ2829I ------- --------- -------- --------- EZZ2771I OSA0402LNK Not Active OSA0602LNK No EZZ2771I OSA0602LNK Active OSA0602LNK Yes There is a Technote which supposedly covers this topic but it needs to have a "health warning" that it is as likely to confuse as elucidate. It would have helped enormously if the author had fully understood what he or she was writing about! "Interface takeover function and gratuitous ARP" http://www-01.ibm.com/support/docview.wss?uid=swg21243821 Actually I had hoped that there was some way that the system would be able to tell you that a particular VIPA had been included in a so-called "LAN Group" but having written up this topic here and checked the CS IP System Administrator’s Commands manual I can't see that you can check this point with any of the supplied commands. You will need to display the ARP cache in the adjacent router on the VLAN, the router with interface IP address 10.254.76.01 I assume, in order to be sure that it includes an entry for the VIPA. It was only on review that I noticed that your set of ROUTE statements doesn't follow the normal, well-understood pattern. The "usual pattern" is to specify a "direct" route, the characteristic of which is to have an "=" sign in the "first hop" position. This "direct" route defines the interface over which IP packets which need to be sent to an "adjacent" router can be sent, an "adjacent" router being one which has an interface which connects to the same (V)LAN as the specified interface. If the configuration is the most straightforward, the only "indirect" route which need be specified is the "default" route. This "default" route specifies a, probably, the "adjacent" router in the "first hop" position and the prior "direct" route is supposed to be necessary in order that the route to the "first hop" is defined. In principle the "direct" route could be assumed since all the information needed is available - but I didn't think it worked like that! Half-way through writing this I imagined there may be a level of confusion reigning in these definitions which was combining a dynamic routing protocol *and* static routing statements. This, if I took the time to try to disentangle it, might explain why you are getting away with not following the "usual pattern" for purely static routes. However, I checked the CS IP Configuration Guide and Reference manuals in order to see if there was actual text - rather than just examples - to support the "usual pattern" and I couldn't find any - so maybe I learned something today! Note I know of old that the "usual pattern" is *required* by routes defined using the GATEWAY statement - or used to be. However again, I could not find any text which made this point - suspicious! Doubling up this "usual pattern" for two interfaces is just fine. However benefitting from having two equivalent interfaces is not permitted by default. >From the description of BEGINROUTES in the CS Configuration Reference manual: <quote> In addition, multiple routes having an identical destination IP address and address mask can be specified. When multiple routes are specified, all of them are used when multipath is enabled on the IPCONFIG/IPCONFIG6 statement; otherwise, only the first active route specified is used. </quote> You need to specify the MULTIPATH parameter of the IPCONFIG statement. You then further need to decide for TCP connections whether to specify PERCONNECTION or PERPACKET. I incline to PERPACKET myself but there are some gurus who are probably watching who favour PERCONNECTION for reasons I forget! Note that IPCONFIG MULTIPATH PERsomething applies only to outbound traffic. If you want to get a similar benefit for inbound traffic, you need to set up suitable definitions within the IP network, possible only in that all- important "adjacent" router. - Now to something of a surprise: you included the TN3270E procedure! > When you talk about TN3270 and TN3270E you mention that there's a comma missing in front of the mode table which makes it a TN3270 without the E. As I'm not sure of what I'm using, let me paste the TN3270E STC job: I don't know why the TN3270E procedure could have anything to do with whether or not you are using TN3270E protocols. One possible explanation - with which I can sympathise - is the rather dumb idea to decide to call the CS IP original non-UNIX TELNET program the "TN3270E" program. I can guess that some idiot "suit" came up with this idea as some sort of marketing ploy without having the foresight that it could confuse - as indeed in your case it would appear to have caused confusion. Actually, the internal function supporting TELNET was called just that as far back as I can easily check, namely in "TCP/IP for MVS" V2R2.1. >From TCP/IP for MVS V2R2.1 Planning and Customization, Chapter 10: <quote> This chapter describes how to configure the Telnet server. The Telnet server is part of TCPIP and acts as an internal client to it. </quote> When the "configuration" manual was reorganised into two manuals between OS/390 V2R8 to OS/390 V2R10 - there were no "communications server" changes for OS/390 V2R9, the "suit" influence must have crept in and the non- UNIX TELNET program became the TN3270 server - quite ignoring the fact that "linemode" was still supported.[4] Although support for TN3270E protocols had been introduced as far back as the change from "TCP/IP for MVS" V3R2 to the IP component of OS/390 Communications Server V2R5 - don't ask! - around 1998, it was only with the z/OS V1R9 Communications Server around 2008[5] - 10 years later! - that the "suits" decided that the non-UNIX TELNET program should be described as the "TN3270E" program thus - probably - causing your confusion! - Of course what I really need to see is the full content of the OMVS.PROD.TCPIP.PARMLIB(TN32&SYSNAME) data set rather than merely the TELNETGLOBALS statement block. Once I see that, I expect to have all the definition information necessary to get back to your original problem! Otherwise what is striking about the procedure are the three data sets, presumably partitioned data sets for object modules, with VTAMLIB as one of the tokens. You have indicated that you are using an USS table and I guess you may well have stored the object module corresponding to that USS table in the same partitioned data set in which you store the USS table object modules required by VTAM and which you include in the VTAMLIB concatenation in your VTAM typically NET, procedure. All of this implies that you need only one of these "VTAMLIB" partitioned data sets in your TN3270E procedure, the one in which you have stored the one or two object modules corresponding to the one or two USS tables which you name on the USSTCP statement. I don't expect you are using any "interpret" tables so I cannot see why you would *not* need to have any other "VTAMLIB" data sets in your STEPLIB concatenation. Note that none of these "corrections" I am suggesting actually changes how the "TN3270E" server program works but whoever tries to solve problems with the "TN3270E" server in the future will thank you not to have quite so many "red herrings" lying around which will need to take up time checking the manuals and working out that they are irrelevant. - Since you have introduced the topic of the TN3270E started task procedure - and you are probably operating a fairly straightforward TN3270 server environment - that is, not one with masses and masses of mapping statements as I have seen installations use, you may like to treat the "TN3270E" server in the same way as you have traditionally handled all your other servers, namely by the use of the AUTOLOG statement list. IBM developers in their questionable wisdom have however introduced a snag! They were so focussed on the customers who screamed out for the possibility to separate the "TN3270E" server from the main CS IP program that they overlooked the simpler folk who suffered twisted arms when they discovered, when installing V1R9 or later from a release prior to V1R9, that the TN3270 function didn't work any more. That is, these more simple customers were, in effect, dragged kicking and, in their turn, screaming into having to set up a separate procedure for the "TN3270E" server. The IBM default PPT entry in module IEFSDPPT for the "TN3270E" program, EZBTNINI, as described in Table 23, "IBM-supplied Program Properties Table (PPT) Values"[6], specifies "Non-cancelable" (NC). If you override this PPT table entry with a SCHEDxx PPT entry as follows, you will be able to use the traditional AUTOLOG function for the "TN3270E" address space just like I guess you have always done for server procedures dependent on the main CS IP program address space: PPT PGMNAME(EZBYNINI) CANCEL Key(6) NOSWAP PRIV SYST If you ever want to run the TN3270E started task procedure with multiple job steps, you can also just omit the SYST attribute - or specify NOSYST - and place TIME=1440 on the EZBTNINI step. - I can perhaps take this opportunity to have a look at the statements other than the TELNETDEVICE statements in the TELNETGLOBALS statement block you posted. > CodePage ISO8859-1 IBM-1047 The CODEPAGE statement applies only to "linemode" sessions/connections. >From the CS IP Configuration Reference manual: <quote> CODEPAGE statement Use the CODEPAGE parameter statement to specify ASCII-EBCDIC translation tables for linemode connections. </quote> In any case what you have specified appears to be the default for EBCDIC/ASCII translation. > Inactive 1800 This specifies an interval of 1/2 hour for no activity on the SNA session/TN3270 TCP connection. Also, because a timer of exactly 1 800 seconds is used according to the rule that the smallest - if not 0 - of the timers specified or defaulted for the KEEPINACTIVE, INACTIVE, PROFILEINACTIVE and PRTINACTIVE is used to monitor these events and two are 0 while the only other with a non-zero value is also 1 800. However this is, I believe, what you expect as a the timeout and not just the few minutes you are reporting. >...> The problem is that a user is timed out after a 2-3 minutes and it takes the user all the way back to the USSTAB. I believe I may have misunderstood the "all the way back to the USSTAB". If there really is a disconnection of the TN3270 TCP connection but the TN3270 client logic immediately re-establishes the session - and you do not have a DEFAULTAPPL/DEFAPPL applying to the TN3270 connection, that will look to the end-user as "all the way back to the USSTAB" although it will really be "all the way back" to no connection with an automatic reconnection. I based a lot of my earlier guesswork on what your "TN3270E" server customization was on the assumption that there was no disconnection so all that effort may well have been wasted! >...> In CICS I have coded USRDELAY=30 ... I assume that this CICS parameter is the equivalent to the 1/2 hour "no traffic" check in the "TN3270E" server. I guess it will be interesting to see which of these session termination mechanisms wins. It's probably advisable in terms of consistent behaviour to rely on just one of these mechanisms and I suspect it might be cleverer to rely on the CICS mechanism and set INACTIVE 3600 or something like that in order that the "TN3270E" server mechanism acts as a sort-of "backup". > TimeMark 1800 > ScanInterval 120 What these specifications do is check for whether a connection exists or not. They are like the INACTIVE parameter in that the associated mechanism is triggered by a lack of activity but the mechanism does not cause disconnection but rather checks whether a disconnection of the TN3270 TCP connection has already happened.[7] This can then have implications for the now orphaned SNA session which had hitherto been concatenated to the TN3270 TCP connection. In the case of the specified values, TN3270 TCP connections are checked for activity every 2 minutes (120 seconds) and, if there has been no visible traffic for a total of 15 consecutive checks (15 x 120 = 1 800), the "timemark" mechanism is invoked in order to see whether or not the TN3270 TCP connection still works. If it does not work some element of the IP network path is deemed to be taking an unplanned rest and, after another 2 minutes when the check is made, the TN3270 TCP connection is "cleaned up". >...> ... and in the TCP/IP profile parm we coded interval 120 on the TCPCONFIG card. The INTERVAL parameter on the TCPCONFIG statement behaves somewhat like the TIMEMARK statement. However it concerns itself with all TCP connections not just - obviously - TN3270 TCP connections. Yet again however, we have two mechanisms performing the same job and it might be advisable for consistent behaviour to rely just on one and use the other for some sort of "backup". Having written that I actually dipped into the manual in order to be sure about what I was saying. I was then reminded that, since the "TN3270E" server provides for its own "keepalive" facility, it probably has no interest whatsoever at all in the mechanism provided by the TCP logic and I would expect just does not enable the TCP-based "keepalive" mechanism. In order for an application using TCP to get the benefit of the TCP "keepalive" mechanism, it is necessary either that the application issues the SO_KEEPALIVE call and it will then use the checking interval value specified by the INTERVAL parameter or that the application issues the TCP_KEEPALIVE call and it will then use the checking interval value specified by the TCP_KEEPALIVE call itself. - I appreciate that none of this helps with your problem but - with the full "TN3270" PROFILE data set to hand - and some clarity concerning the behaviour of the TN3270 clients following disconnection - we will have all the facts I can think of for the moment. Also once I see what I expect is the DEFAULTLUS/ENDDEFAULTLUS block, I expect I will have a better idea of what those events are that you reported in an earlier post which I can now see are probably an identification of the SNA sessions associated with the TN3270 TCP connections. Before sending, I took another look at those apparently diagnostic messages provided I expect by some sort of "user" exit in your CICS system. Unfortunately I can see they say something but I'm unsure precisely what it is. For example, "signons" are not matched with "signoffs" so I'm not clear what the "signon" and "signoffs" mean. There may be some log provided by the TN3270E procedure which describes what events the "TN3270E" server program "sees". - Chris Mason [1] There was also the following explanation regarding the SESSLIM operand: <quote> Because the TCP/IP LU code cannot handle multiple concurrent sessions, you must code SESSLIM=YES for each TELNET LU defined to VTAM. Otherwise, if SESSLIM=NO, menu or session manager applications that use 'return session' processing might cause session termination. </quote> An effectively identical statement can be found inn the latest, V1R12, CS Configuration Guide. It's actually an open issue quite how the SHAREACB function introduced in V1R12 could work if SESSLIM=YES is specified. I'll need to look into this. It may be that the logic of session managers - I suspect when working in "pass", as opposed to the more usual "relay", mode - may need to be adjusted in order to take account of the SHAREACB function. [2] Just to cover a question that may come to mind, the PRIROUTER and SECROUTER parameters are replaced by the VMAC ROUTEALL parameter. The fact that no "pri"/"sec" distinction need be made is a tribute to the superiority of the mechanism associated with the VMAC parameter. [3] Where in the manuals does it actually say this? Nowhere! Then how do I know. Well ...: 1. There is no AUTORESTART parameter on any INTERFACE statement type which are, with the single but very important exception of the OSA QDIO IPv4 INTERFACE statement, for IPv6. 2. In the description of the DEVRETRYDURATION parameter of the IPCONFIG statement we find the following: <quote> For IPv6 interfaces, the autorestart function is always active. </quote> Could it be that the poor overworked lambs of authors just missed making the addition "and the IPv4 OSA QDIO interface" when that INTERFACE statement was introduced? [4] I jumped on someone in one of the lists for calling the "TELNET server" the "TN3270 server" and it was gently and quietly suggested I actually take a look in the manual before making any point based purely on logic! [5] z/OS V1R9 was the first release to drop support for what we must subsequently train ourselves to call the "TN3270E server" as an "internal client". [6] http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA2E2B0/75.7 It looks like the CS IP developers' hearts were not really in this ludicrous name change which the "suits" insisted upon and so they forgot to pass on to the z/OS developers that the name should be changed in this table from "TN3270" to "TN3270E"! [7] The text explaining the operation of the TIMEMARK parameter mentions that the TN3270 TCP "connection" is disconnected, actually "dropped", when there is no response to sending the "timemark". This "disconnection" is actually just "cleaning up" the TN3270 server side of the TN3270 TCP connection and is not a usual "disconnection" since there is evidently no communication with the TN3270 client side of the previous real connection. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
