Re: Emulator Sessions Hung
Dave Kopischke wrote: But VTAM is activating them prior to that. Is this the proper sequence ??? VTAM -- TN3270 -- Applications ??? It seems logical to me, but this whole quest has been an experience... VTAM and OMVS services if needed -- TCPIP -- TN3270 -- Apps using these comm services. HTH! Groete / Greetings Elardus Engelbrecht -- 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
Re: Emulator Sessions Hung
On Wed, 23 Jun 2010 03:34:46 -0500, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Dave Kopischke wrote: But VTAM is activating them prior to that. Is this the proper sequence ??? VTAM -- TN3270 -- Applications ??? It seems logical to me, but this whole quest has been an experience... VTAM and OMVS services if needed -- TCPIP -- TN3270 -- Apps using these comm services. Good point. I'll take a look and see when OMVS becomes available. We do get messages indicating some services are waiting for OMVS to initialize, but I don't recall which. Thanks, Dave K. -- 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
Re: Emulator Sessions Hung
Dave 10171 21:21:24.56 STC04120 IEF403I TN3270D - STARTED Thank you for indicating that the TN3270 server involved is the z/OS Communications Server (CS) TN3270E server - albeit somewhat indirectly! I am about to describe what I ***think*** you are trying to do. If it isn't, I'd better start off with an apology over possibly harsh words to follow! My first reaction was annoyance at your inability to produce the full picture from the very beginning instead of wasting the time of a number of specialists who probably have much better things to do. That's less so in my case since I am currently what the theatrical profession calls resting and this sort of stuff keeps the brain exercised. Then I reflected that probably you were not responsible for the design, that the person who was had been let go without having passed on all the wisdom enshrined in his or her designs and that you did not appreciate that there are other ways of setting up 3270 communication from CICS to a 3270 emulator via SNA and TN3270 which folk are going to try to fit to your environment - and get into a tangle so doing! Thus you considered that some aspects of the design were just so obvious as not to be worth mentioning! Incidentally, it may be that the design you are using can be quite effective - but it's not the best! Anyhow, the scenario which I surmised is as follows - and please excuse repetition in the cause of producing a complete story: a. Your 3270 emulator as a TN3270E client is set up automatically to try to establish TN3270E connections, perhaps by trying, and, if failing, waiting, say, 30 seconds and trying again. b. Your TN3270E client specifies a name intended to serve as a means to select the name of a SNA secondary LU managed by the TN3270E server which acts as the concatenation point for the TN3270E connection and the SNA session. It may even, with rather a considerable risk of being misleading, be identified as an LU name - which it can never actually be since how that name is handled is a matter for the TN3270E server. c. The connection attempts will succeed only when the CS TN3270E server has been started and the underlying CS TCP and IP logic can interwork with a newly opened TCP socket in passive (listening) mode. In other words, you are correct in appreciating that the order with which z/OS components are initialised is a key consideration. d. The CS TN3270E server has been customised so that the TN3270E server sends a 3270 data stream panel to the TN3270E client which appears on the 3270 emulator window. This is your curiously - and actually misleadingly - named VTAM splash. The panel is sent from a CS IP library purely by the TN3270E server program. VTAM has no part in the sending of this Unformatted System Services (USS) message 10, nor in any subsequent USS messages which may be needed, nor in the USS commands which may be entered. VTAM is involved *only* because it is the VTAM (CS SNA) development shop which maintains the USS macros from which the commands and messages are built and it was VTAM which invented the USS function back in the mid-'70s to be taken up by TCP/IP for MVS or CS IP - I'm not sure of dates! - much later in order to pretend to operators that all was well in the world and that SNA in the shape of VTAM was still taking care of them and not this rickety IP thing! [1] e. I'm having to guess at a plausible scenario but note others might apply. I'm going to suggest that the name specified in the TN3270E client is used by the TN3270E server in order specifically to identify a particular APPL statement. f. This is a point that I wasn't quite sure about and cannot check but makes sense. When the TN3270E connection is established, the CS TN3270 server uses its customisation parameters in order to select one of the APPL statements it has been told should have been defined - and be available in CONCT (short for connectable) status - for it. It will now open the ACB with the name selected and the corresponding VTAM resource will change from CONCT to ACTIV status and, logically, an SSCP-LU session will now exist.[2] What I believe happens here is to some extent supported by the way a model APPL statement works. A model APPL statement is converted to the equivalent of a fully defined APPL statement only when the ACB is opened and VTAM discovers what name the application which opened the ACB wants. VTAM can then try to match this name with some flavour of a generic name used by a model APPL statement. f. There is now a wait. The status on the side of the TN3270E connection is that it exists and an USS message 10 can be seen in the 3270 emulator window. On the VTAM side, an application LU has been activated which corresponds to the secondary LU in any eventual session and is considered to be concatenated to a TN3270E connection. g. One hopes that at some time later CICS will become fully initialised and will have
Re: Emulator Sessions Hung
George ... all he needs to do us give you enough information and this problem is history. There's something very odd about this thread. Dave seems to be able to see all/most of the posts except mine - and maybe Gary Loebach can't see mine either. Since it's clear he *can* see your posts, please post again mentioning that some subscribers do not seem to have noticed my posts explicitly mentioning where the archives are to be found: http://alabamamaps.ua.edu/archives/ibm-main.html This is all the more important since I think I have managed to clear a path through the brambles of obfuscation to a probable solution! Thanks Chris Mason On Sun, 20 Jun 2010 05:38:37 -0400, George Henke gahe...@gmail.com wrote: Awesome, Chris. I'm impressed. But, it looks like the ball is now in Dave's court. With your expertise, all he needs to do us give you enough information and this problem is history. -- 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
Re: Emulator Sessions Hung
Dave The one that works on this PC has no messages that I could find based on the LU name. When session setups succeed, there is no message. VTAM's approach to this is that no news is good news or, in other words, messages, particularly the IST663I set of messages, is bad news. Clearly VTAM expects session setups to work in general and to create messages would flood any receiving consoles without purpose. If you need to keep track of all your sessions, NLDM[1] is your man! I'll see if I can find something that possibly groups them together. Maybe that's how they're getting activated ??? Although I think I have found the reason for the session setup failures, if the failures consistently show the same behaviour it may not be (only) a timing effect. Chris Mason [1] NetView's Session Monitor On Sun, 20 Jun 2010 22:37:31 -0500, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 19:16:40 -0400, George Henke gahe...@gmail.com wrote: Thank you, Dave, this is very helpful. I would switch the focus now to the one good Attachmate session on the PC which works. Please trace it through the IPL SYSLOG and note where and how it is activated and how it goes into session. Note its majnode, timing, etc. Then without losing your focus, note, as you go along, any irregularities occurring with the other 3 failing nodes at or about the same time. This is why I posted. Everything for these four definitions is the same. When I found these messages in the syslog, it was searching on LU name. The one that works on this PC has no messages that I could find based on the LU name. I think I might have also mentioned that there is another PC that handles all of our production sessions that has four identical sessions and all four work as expected. I'll see if I can find something that possibly groups them together. Maybe that's how they're getting activated ??? Doh, I think I'm losing focus Thanks for your help. -- 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
Re: Emulator Sessions Hung
Gary I hope some will be able to pick this up even if you can't. I was surprised to see this since it takes no account of my having said I am fairly sure that LOGAPPL cannot be involved because of the lack of the IST890I message and the requirement that VTAM is actually in the process of activating the secondary LU. I think there are a lot of components involved here all trying to start up at IPL. There is VTAM, TCPIP(Telnet), CICS, and the emulator on the PC. From Dave's response where he lists the started task procedures and their starting times there is strong evidence that he is running a main IP program and a TELNET server program, TN3270D, as separate started tasks. I am, of course, assuming that the name TN3270D has some relationship to the function. It is not clear when the main IP address space started since that is not mentioned. ... Each has four emulator sessions defined and running. When we IPL, one set of sessions on one PC come back alive just fine. Of the four sessions on the other PC, only one comes back alive. I believe he has told us that the PC emulators stay active and expect to re- establish TN3270 TCP connections automatically presumably using continuous repeated connection attempts. Probably that's the start up which you have in mind. ... VTAM is doing autolog for those simulated devices that haven't had their ACBs opened yet. This would imply that VTAM autologs - I assume you mean that VTAM is responding to a LOGAPPL operand - before the APPL statement changed from CONCT to ACTIV - which I believe does *not* happen. In the old days when I had systems to hand with which to play, I could have verified all of this. Now I have to leave it to those of you lucky enough to have sandpits to hand. Incidentally, if you are using model APPL statements as is generally encouraged these days in order to support TN3270 secondary APPL statements, the APPL statement does not exist until the ACB has been opened by the supporting program, the TN3270E server in this case, and the APPL statement is defined - with ACTIV status, of course - which implies the existence of the SSCP-LU session of course. Which is probably producing the error you see. The error he sees is an absence of an SSCP-SLU session, sense code 08570003. Chris Mason On Mon, 21 Jun 2010 08:32:48 -0500, Gary Loebach gary.loeb...@ca.com wrote: I think there are a lot of components involved here all trying to start up at IPL. There is VTAM, TCPIP(Telnet), CICS, and the emulator on the PC. I would think it is just a timing problem in that all the components needing to be active to autolog are just not ready yet. I suspect Telnet is opening ACBs for each of the simulated 3270 devices and when CICS starts, VTAM is doing autolog for those simulated devices that haven't had their ACBs opened yet. Which is probably producing the error you see. I suspect the ACB openings are a bit serialized in a few task in Telnet, so given that some of the ACB may be open and some not yet while autolog is kicking off. You say if you bounce the CICS region everything comes up, would support this theory since at that point Telnet is completely up. If this is what is happening then for IPL we would need to delay the start of the CICS regions until Telnet gets fully initialized and then I think all those session would come up. -- 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
Re: Emulator Sessions Hung
Dave I checked all the VTAM definitions and they're all identical. I don't see a LOGAPPL association to these. When I displayed it, there is no CONTROLLING LU in the output. There are a bunch of LOGAPPL statements in other members, ... So, assuming other members means that there are no LOGAPPL operands - not statements by the way - defined on the APPL statements which define the SNA secondary LUs managed by the TN3270E server in order to concatenate TN3270 connections to an SNA session, the AUTOLOG mechanism is *not* involved. ... but the LOGAPPL statements seem to relate to an LU. If the LOGAPPL *operands* are defined on LU statements then the purpose they serve is to cause VTAM to initiate a session between the referenced primary application LU, typically a program using the VTAM API such as CICS, and the secondary LU resource represented by the LU statement - in this case when the LU is activated - and the SSCP-LU session is started. If the definition order is APPL -- LU, then there are none. The only references to these terminal definitions by name in the whole VTAMLST is in the member that defines them. What I just said about the LU statement with the LOGAPPL operand specified has nothing to do with the resources represented by the APPL statements associated with the TN3270E server - which I think is what you are saying but just to be sure. Chris Mason On Mon, 21 Jun 2010 12:21:36 -0500, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 18:18:04 -0500, Richard Peurifoy r- peuri...@neo.tamu.edu wrote: Have you checked the definitions in VTAMLST to make sure they don't specify LOGAPPL=xxx This will also show up on a D NET,ID=terminalluname,E as CONTROLLING LU = applid I checked all the VTAM definitions and they're all identical. I don't see a LOGAPPL association to these. When I displayed it, there is no CONTROLLING LU in the output. There are a bunch of LOGAPPL statements in other members, but it's not real clear to me how the associations are made. The PC sessions are defined as APPL's, but the LOGAPPL statements seem to relate to an LU. If the definition order is APPL -- LU, then there are none. The only references to these terminal definitions by name in the whole VTAMLST is in the member that defines them. -- 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
Re: Emulator Sessions Hung
But VTAM is activating them prior to that. Is this the proper sequence ??? VTAM -- TN3270 -- Applications ??? This is the right sequence. Get the communication services up first then the applications. Gary -- 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
Re: Emulator Sessions Hung
I think there are a lot of components involved here all trying to start up at IPL. There is VTAM, TCPIP(Telnet), CICS, and the emulator on the PC. I would think it is just a timing problem in that all the components needing to be active to autolog are just not ready yet. I suspect Telnet is opening ACBs for each of the simulated 3270 devices and when CICS starts, VTAM is doing autolog for those simulated devices that haven't had their ACBs opened yet. Which is probably producing the error you see. I suspect the ACB openings are a bit serialized in a few task in Telnet, so given that some of the ACB may be open and some not yet while autolog is kicking off. You say if you bounce the CICS region everything comes up, would support this theory since at that point Telnet is completely up. If this is what is happening then for IPL we would need to delay the start of the CICS regions until Telnet gets fully initialized and then I think all those session would come up. -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 18:18:04 -0500, Richard Peurifoy r- peuri...@neo.tamu.edu wrote: Have you checked the definitions in VTAMLST to make sure they don't specify LOGAPPL=xxx This will also show up on a D NET,ID=terminalluname,E as CONTROLLING LU = applid I checked all the VTAM definitions and they're all identical. I don't see a LOGAPPL association to these. When I displayed it, there is no CONTROLLING LU in the output. There are a bunch of LOGAPPL statements in other members, but it's not real clear to me how the associations are made. The PC sessions are defined as APPL's, but the LOGAPPL statements seem to relate to an LU. If the definition order is APPL -- LU, then there are none. The only references to these terminal definitions by name in the whole VTAMLST is in the member that defines them. -- 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
Re: Emulator Sessions Hung
On Mon, 21 Jun 2010 08:32:48 -0500, Gary Loebach gary.loeb...@ca.com wrote: I think there are a lot of components involved here all trying to start up at IPL. There is VTAM, TCPIP(Telnet), CICS, and the emulator on the PC. I would think it is just a timing problem in that all the components needing to be active to autolog are just not ready yet. I suspect Telnet is opening ACBs for each of the simulated 3270 devices and when CICS starts, VTAM is doing autolog for those simulated devices that haven't had their ACBs opened yet. Which is probably producing the error you see. I suspect the ACB openings are a bit serialized in a few task in Telnet, so given that some of the ACB may be open and some not yet while autolog is kicking off. You say if you bounce the CICS region everything comes up, would support this theory since at that point Telnet is completely up. If this is what is happening then for IPL we would need to delay the start of the CICS regions until Telnet gets fully initialized and then I think all those session would come up. We may have a winner here... I went through and lined up the various pieces that I've discovered so far... 10171 21:18:24.44 SYSLOG IEE042I SYSTEM LOG DATA SET INITIALIZED 10171 21:18:30.79 STC03994 0080 IST093I APTCP ACTIVE 10171 21:20:35.66 STC04089 0084 $HASP373 TESTTRN STARTED 10171 21:20:35.63 STC04088 0084 $HASP373 TESTOLD STARTED 10171 21:21:24.56 STC04120 IEF403I TN3270D - STARTED 10171 21:22:38.42 STC03994 0084 IST663I INIT OTHER REQUEST FAILED, PCOPO3 10171 21:22:38.42 STC03994 0084 IST663I INIT OTHER REQUEST FAILED, PCOPO4 10171 21:22:39.72 STC03994 0084 IST663I INIT OTHER REQUEST FAILED, PCOPO6 While the production CICS's actually start earlier, they are much larger and take a longer to initialize. Maybe that's what allows them to connect up OK while the test terminals consistently don't ??? TN3270 seems to be ready about a second prior to the terminals being accessed, so this might not be the cause. It's close enough to give it a shot though. In any event, I moved the TN3270 start up prior to the CICS start ups. That should give it enough time to complete initialization prior to CICS looking for them. But VTAM is activating them prior to that. Is this the proper sequence ??? VTAM -- TN3270 -- Applications ??? It seems logical to me, but this whole quest has been an experience... -- 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
Re: Emulator Sessions Hung
Awesome, Chris. I'm impressed. But, it looks like the ball is now in Dave's court. With your expertise, all he needs to do us give you enough information and this problem is history. On Sat, Jun 19, 2010 at 8:10 PM, Chris Mason chrisma...@belgacom.netwrote: George Yes, I thought about LOGAPPL as something to mention in my first response but then I rejected it - and that was before I spotted that the dog didn't bark in the night, that is, the IST890I message was missing. The reason I rejected it was that, in order for the mechanism associated with the LOGAPPL operand to be fired off by VTAM, VTAM has to have the primary LU application active - strictly enabled for logons - and the secondary LU has to be activated and enabled. If the secondary LU has been activated it *must* have an SSCP-LU session in place. If an SSCP-LU session is in place, sense code 08970003 cannot apply. In case, the sense codes were being lazy, I even checked that there is a sense code for being active but not enabled, 083A0002. But since the mechanism needs the secondary LU to be enabled even this would not have been seen. LOGAPPL and this AUTOLOGON process is quite interesting. When APPN was introduced, it went from being completely reliable in the subarea context to becoming flaky in the APPN context. Hence the AUTORTRY and AUTOTI start options were introduced as a way of trying to compensate. Since I had to teach APPN VTAM, I took some interest in this process. Well, I just checked my notes, I actually cover this topic in my non-APPN VTAM presentation notes since I already had the LOGAPPL topic covered and I need to incorporate the AUTORTRY and AUTOTI start options. I checked all those notes and I cannot see - even when the named application resides with another VTAM - a VTAM restart (as part of the IPL) could cause the effect Dave Kopischke observes. We are still labouring under the considerable handicap of not having been told by Dave what flavour of TN3270 server he is using. Assuming it is the OSA- ICC, there is a point to get out of the way. I tried to see if there was anything in Chapter 11, Programming for the IBM 3270 Information Display System of the z/OS Communications Server SNA Programming manual regarding what might be said concerning a pre/non-SNA channel-attached 3270 device which was just not there, the equivalent of powered off which is I believe how the OSA-ICC behaves when there is no TN3270 TCP connection in place. There was nothing, so it seems that the LU will be considered to have an SSCP-LU session in place and be enabled when the LOCAL statement has been activated. The LOGAPPL acts like a VARY ACT, ACQ ... Only when VTAM is prompted by the secondary LU definition with LOGAPPL specified becoming active and enabled. ... if the APPL it is trying to Bind the terminal to is non-existent, not ready, or whatever, the blank or whatever screen on the 3 failing devices is typically the result. A primary LU (application) will not send a BIND to a secondary LU unless there has been a successful session setup first. It is the session *setup* to which the message group headed by the IST663I message refers. There is, of course an exception to this bare statement which does not apply here which is a LEN session setup. Such a session can be initiated purely by sending a BIND request - and it doesn't actually need to be an LU type 6.2 session but that's another story ... It may even be something missing in TCPPARMS. It won't be any sort of TCPPARMS data set or member if the TN3270 server is an OSA-ICC. 1) The problem occurs only after IPL Yes 2) The devices come up inactive It's not quite clear what Dave's inactive is. 3) To start the sessions, Attachmate must be restarted. I think there is some sort of restart of the TN3270 client program. Chris Mason On Sat, 19 Jun 2010 16:40:45 -0400, George Henke gahe...@gmail.com wrote: Chris, I like Richard Puerifoy's suggestion, which cuts to the chase, to check that the LOGAPPL parameter for these devices in VTAMLST is not coded with something strange. How many times have we seen that happen? The LOGAPPL acts like a VARY ACT, ACQ and if the APPL it is trying to Bind the terminal to is non-existent, not ready, or whatever, the blank or whatever screen on the 3 failing devices is typically the result. You may still be right, though, about it being a timing problem. It may even be something missing in TCPPARMS. We just don't know enough yet. Every lawyer knows get all the facts because just one missing fact can change the entire case. The problem with shooting network problems like these is that there are soo many things that can go wrong. So the first job is to stay focused. The most telling facts so far are: 1) The problem occurs only after IPL 2) The devices come up inactive 3) To start the sessions, Attachmate must be restarted. On
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 19:16:40 -0400, George Henke gahe...@gmail.com wrote: Thank you, Dave, this is very helpful. I would switch the focus now to the one good Attachmate session on the PC which works. Please trace it through the IPL SYSLOG and note where and how it is activated and how it goes into session. Note its majnode, timing, etc. Then without losing your focus, note, as you go along, any irregularities occurring with the other 3 failing nodes at or about the same time. This is why I posted. Everything for these four definitions is the same. When I found these messages in the syslog, it was searching on LU name. The one that works on this PC has no messages that I could find based on the LU name. I think I might have also mentioned that there is another PC that handles all of our production sessions that has four identical sessions and all four work as expected. I'll see if I can find something that possibly groups them together. Maybe that's how they're getting activated ??? Doh, I think I'm losing focus Thanks for your help. -- 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
Re: Emulator Sessions Hung
George There's no need to apologise. There's been a misunderstanding based on my lack of elaboration in my initial statement: 'Everything obvious' includes particularly any error messages should have been I would have imagined that 'Everything obvious' would have included particularly seeking out any error messages but there's no accounting for the rather peculiar approach some system programmers adopt to problem determination. So you were quite right to take Dave Kopischke back to basics. -- But let's do a Rumsfeld - apparently based on an idea which originated with Confucius - on this problem, first regarding what it is we are dealing with here: - From the post of Fri 11:45:20 -0600: - We are dealing with an emulator, presumably a 3270 emulator. - There is a reference to sessions, so the 3270 emulator is supposed to be in communications with something supporting a VTAM API (although that *may* be presumptuous if it turns out the application is VTAM's Unformatted System Services) - coming back after IPL indicates that the 3270 emulator is expected to initiate the communication to something in the vicinity of VTAM. - Some instances of the 3270 emulator succeed - 4 out of 4 in one case and 1 out of 4 in another case - and some do not - 3 out of the 4 in the latter case. - Naturally there are some definitions involved and they are described as sessions although the word session may very well be being thoroughly misused.[1] - It is let slip that not only is VTAM involved but also TN3270 but what flavour of TN3270 emulator is unclear and remains unclear in the subsequent posts at the time of writing. - It is also let slip that CICS is involved so we now should be able to conclude that the intent is that the communications is all the way through the VTAM API to CICS. I think what is being said about CICS is that it can be stopped and started independently of the IPL and the 3270 emulators establish communications without unexpected problems, perhaps entirely without human intervention. - From the post of Fri 14:39:54 -0500 as a result of questions from Patrick Lyon: - There could be a mystery that Connectivity to the host is lost. with some 3270 emulator windows but not with the one which succeeds. This simply raises the question of what connectivity might be supposed to mean. I would consider that it was impossible that connectivity was lost if there were at least one successful case of communication with both the PCs. Perhaps Dave simply meant to say that connectivity was lost during the IPL. - It is confirmed that the 3270 emulators are operating as TN3270 clients and that something more in the vicinity of VTAM is behaving as a TN3270 server. Inclusive but not exclusive options are the z/OS Communications Server TN3270E server, probably running these days as a separate address space, or an OSA-ICC TN3270 server. - Confusion is now added in that Dave now tells us that he expects communication between the 3270 emulator and minimally VTAM to be confirmed by the appearance of an USS message 10, rather approximately described by Patrick Lyon as a USSTAB.[2] Since Dave expressed concern about CICS before and confirmed that stopping and starting CICS did not reveal the same problem - described just about inevitably these days as an issue of course - we are left with an outstanding question: should successful communication be indicated by an USS message 10 or a CICS good morning transaction message - or whatever the equivalent is these days. Incidentally, if it is now certain that there is a TN3270 server on the communication path, we can more accurately describe the communication as a TN3270, possibly TN3270E, TCP connection between a TN3270 client 3270 emulator and a TN3270 server of some sort. This connection can be concatenated to an SNA session in one of two ways: 1. The TN3270 server acts as a secondary LU to an, in this case, CICS application using the VTAM API as a primary LU. If the TN3270 server is the z/OS Communications Server TN3270E server, the secondary LU will be defined though an APPL statement. 2. The TN3270 server acts as a pre/non-SNA 3270 channel-attached device. This device is allocated to VTAM and the channel programming terminates in VTAM simulation logic so that it can then represent a secondary LU, defined through a LOCAL statement, to an, in this case, CICS application using the VTAM API as a primary LU. - From the post of Fri 14:40:59 -0500 as a result of questions from Michael Saraco: - TN3270 has both these PC's IP addresses listed as KEEPALIVE. After scanning though the z/OS Communications Server Configuration Reference manual suspecting that KEEPALIVE might be one of those murky TN3270 parameters that I have to read up on every time I need to try to understand them, I discovered that KEEPALIVE applies only to FTP (and NAT) and, of course, the sockets API and is unrelated to the TN3270 server
Re: Emulator Sessions Hung
Chris, I like Richard Puerifoy's suggestion, which cuts to the chase, to check that the LOGAPPL parameter for these devices in VTAMLST is not coded with something strange. How many times have we seen that happen? The LOGAPPL acts like a VARY ACT, ACQ and if the APPL it is trying to Bind the terminal to is non-existent, not ready, or whatever, the blank or whatever screen on the 3 failing devices is typically the result. You may still be right, though, about it being a timing problem. It may even be something missing in TCPPARMS. We just don't know enough yet. Every lawyer knows get all the facts because just one missing fact can change the entire case. The problem with shooting network problems like these is that there are soo many things that can go wrong. So the first job is to stay focused. The most telling facts so far are: 1) The problem occurs only after IPL 2) The devices come up inactive 3) To start the sessions, Attachmate must be restarted. On Sat, Jun 19, 2010 at 1:43 PM, Chris Mason chrisma...@belgacom.netwrote: George There's no need to apologise. There's been a misunderstanding based on my lack of elaboration in my initial statement: 'Everything obvious' includes particularly any error messages should have been I would have imagined that 'Everything obvious' would have included particularly seeking out any error messages but there's no accounting for the rather peculiar approach some system programmers adopt to problem determination. So you were quite right to take Dave Kopischke back to basics. -- But let's do a Rumsfeld - apparently based on an idea which originated with Confucius - on this problem, first regarding what it is we are dealing with here: - From the post of Fri 11:45:20 -0600: - We are dealing with an emulator, presumably a 3270 emulator. - There is a reference to sessions, so the 3270 emulator is supposed to be in communications with something supporting a VTAM API (although that *may* be presumptuous if it turns out the application is VTAM's Unformatted System Services) - coming back after IPL indicates that the 3270 emulator is expected to initiate the communication to something in the vicinity of VTAM. - Some instances of the 3270 emulator succeed - 4 out of 4 in one case and 1 out of 4 in another case - and some do not - 3 out of the 4 in the latter case. - Naturally there are some definitions involved and they are described as sessions although the word session may very well be being thoroughly misused.[1] - It is let slip that not only is VTAM involved but also TN3270 but what flavour of TN3270 emulator is unclear and remains unclear in the subsequent posts at the time of writing. - It is also let slip that CICS is involved so we now should be able to conclude that the intent is that the communications is all the way through the VTAM API to CICS. I think what is being said about CICS is that it can be stopped and started independently of the IPL and the 3270 emulators establish communications without unexpected problems, perhaps entirely without human intervention. - From the post of Fri 14:39:54 -0500 as a result of questions from Patrick Lyon: - There could be a mystery that Connectivity to the host is lost. with some 3270 emulator windows but not with the one which succeeds. This simply raises the question of what connectivity might be supposed to mean. I would consider that it was impossible that connectivity was lost if there were at least one successful case of communication with both the PCs. Perhaps Dave simply meant to say that connectivity was lost during the IPL. - It is confirmed that the 3270 emulators are operating as TN3270 clients and that something more in the vicinity of VTAM is behaving as a TN3270 server. Inclusive but not exclusive options are the z/OS Communications Server TN3270E server, probably running these days as a separate address space, or an OSA-ICC TN3270 server. - Confusion is now added in that Dave now tells us that he expects communication between the 3270 emulator and minimally VTAM to be confirmed by the appearance of an USS message 10, rather approximately described by Patrick Lyon as a USSTAB.[2] Since Dave expressed concern about CICS before and confirmed that stopping and starting CICS did not reveal the same problem - described just about inevitably these days as an issue of course - we are left with an outstanding question: should successful communication be indicated by an USS message 10 or a CICS good morning transaction message - or whatever the equivalent is these days. Incidentally, if it is now certain that there is a TN3270 server on the communication path, we can more accurately describe the communication as a TN3270, possibly TN3270E, TCP connection between a TN3270 client 3270 emulator and a TN3270 server of some sort. This connection can be concatenated to an SNA session in one of two ways: 1. The
Re: Emulator Sessions Hung
Dave These VTAM message groups do not feature an IST890I[1] message. I think you should expect to see that message if you have the ASIRFMSG start option with the default value of OLUSSCP or you have specified ASIRFMSG=ALLSSCP and the session setup which fails is caused by a LOGAPPL specification. If you have specified ASIRFMSG=NONE, you will, of course, not receive IST890I messages. quote Autologon session setup failure IST890I AUTOLOGON SESSION SETUP FAILED This message indicates that an autologon attempt to a controlling PLU failed. The autologon could have originated from one of the following: - VARY LOGON or VARY ACT with LOGON command - VARY ACT command that applied to LUs with LOGAPPL specified - Reallocation of the controlling PLU session /quote This would seem to suggest all this fuss about LOGAPPL is another red herring - but who knows? ... Chris Mason [1] IST890I AUTOLOGON SESSION SETUP FAILED On Fri, 18 Jun 2010 14:59:45 -0500, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 14:40:16 -0400, George Henke gahe...@gmail.com wrote: All PD starts with an error message or error code. Please check the SYSLOG at IPL time, the VTAM log, and the CICS MSGLOG. I didn't notice these in my first pass IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTOLD REAL DLU=SSINET.PCOPO3 IST889I SID = D5DBA179299B6BFD IST264I REQUIRED RESOURCE PCOPO3 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO5 IST889I SID = D5DBA179299B6BF6 IST264I REQUIRED RESOURCE PCOPO5 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO6 IST889I SID = D5DBA179299B6BF7 IST264I REQUIRED RESOURCE PCOPO6 NOT ACTIVE IST314I END -- 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
Re: Emulator Sessions Hung
George Yes, I thought about LOGAPPL as something to mention in my first response but then I rejected it - and that was before I spotted that the dog didn't bark in the night, that is, the IST890I message was missing. The reason I rejected it was that, in order for the mechanism associated with the LOGAPPL operand to be fired off by VTAM, VTAM has to have the primary LU application active - strictly enabled for logons - and the secondary LU has to be activated and enabled. If the secondary LU has been activated it *must* have an SSCP-LU session in place. If an SSCP-LU session is in place, sense code 08970003 cannot apply. In case, the sense codes were being lazy, I even checked that there is a sense code for being active but not enabled, 083A0002. But since the mechanism needs the secondary LU to be enabled even this would not have been seen. LOGAPPL and this AUTOLOGON process is quite interesting. When APPN was introduced, it went from being completely reliable in the subarea context to becoming flaky in the APPN context. Hence the AUTORTRY and AUTOTI start options were introduced as a way of trying to compensate. Since I had to teach APPN VTAM, I took some interest in this process. Well, I just checked my notes, I actually cover this topic in my non-APPN VTAM presentation notes since I already had the LOGAPPL topic covered and I need to incorporate the AUTORTRY and AUTOTI start options. I checked all those notes and I cannot see - even when the named application resides with another VTAM - a VTAM restart (as part of the IPL) could cause the effect Dave Kopischke observes. We are still labouring under the considerable handicap of not having been told by Dave what flavour of TN3270 server he is using. Assuming it is the OSA- ICC, there is a point to get out of the way. I tried to see if there was anything in Chapter 11, Programming for the IBM 3270 Information Display System of the z/OS Communications Server SNA Programming manual regarding what might be said concerning a pre/non-SNA channel-attached 3270 device which was just not there, the equivalent of powered off which is I believe how the OSA-ICC behaves when there is no TN3270 TCP connection in place. There was nothing, so it seems that the LU will be considered to have an SSCP-LU session in place and be enabled when the LOCAL statement has been activated. The LOGAPPL acts like a VARY ACT, ACQ ... Only when VTAM is prompted by the secondary LU definition with LOGAPPL specified becoming active and enabled. ... if the APPL it is trying to Bind the terminal to is non-existent, not ready, or whatever, the blank or whatever screen on the 3 failing devices is typically the result. A primary LU (application) will not send a BIND to a secondary LU unless there has been a successful session setup first. It is the session *setup* to which the message group headed by the IST663I message refers. There is, of course an exception to this bare statement which does not apply here which is a LEN session setup. Such a session can be initiated purely by sending a BIND request - and it doesn't actually need to be an LU type 6.2 session but that's another story ... It may even be something missing in TCPPARMS. It won't be any sort of TCPPARMS data set or member if the TN3270 server is an OSA-ICC. 1) The problem occurs only after IPL Yes 2) The devices come up inactive It's not quite clear what Dave's inactive is. 3) To start the sessions, Attachmate must be restarted. I think there is some sort of restart of the TN3270 client program. Chris Mason On Sat, 19 Jun 2010 16:40:45 -0400, George Henke gahe...@gmail.com wrote: Chris, I like Richard Puerifoy's suggestion, which cuts to the chase, to check that the LOGAPPL parameter for these devices in VTAMLST is not coded with something strange. How many times have we seen that happen? The LOGAPPL acts like a VARY ACT, ACQ and if the APPL it is trying to Bind the terminal to is non-existent, not ready, or whatever, the blank or whatever screen on the 3 failing devices is typically the result. You may still be right, though, about it being a timing problem. It may even be something missing in TCPPARMS. We just don't know enough yet. Every lawyer knows get all the facts because just one missing fact can change the entire case. The problem with shooting network problems like these is that there are soo many things that can go wrong. So the first job is to stay focused. The most telling facts so far are: 1) The problem occurs only after IPL 2) The devices come up inactive 3) To start the sessions, Attachmate must be restarted. On Sat, Jun 19, 2010 at 1:43 PM, Chris Mason chrisma...@belgacom.netwrote: George There's no need to apologise. There's been a misunderstanding based on my lack of elaboration in my initial statement: 'Everything obvious' includes particularly any error messages should have been I would have imagined that
Re: Emulator Sessions Hung
Dave Something I forgot to add to my previous post: What do you see in NetView Session Manager (Network Logical Data Manager = NLDM) regarding the activation of the resources corresponding to your secondary LUs over the time following the IPL? This product was designed exactly in order to solve this sort of problem - and many others of greater complexity. I hope NetView was active in time! Chris Mason On Fri, 18 Jun 2010 14:59:45 -0500, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 14:40:16 -0400, George Henke gahe...@gmail.com wrote: All PD starts with an error message or error code. Please check the SYSLOG at IPL time, the VTAM log, and the CICS MSGLOG. I didn't notice these in my first pass IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTOLD REAL DLU=SSINET.PCOPO3 IST889I SID = D5DBA179299B6BFD IST264I REQUIRED RESOURCE PCOPO3 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO5 IST889I SID = D5DBA179299B6BF6 IST264I REQUIRED RESOURCE PCOPO5 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO6 IST889I SID = D5DBA179299B6BF7 IST264I REQUIRED RESOURCE PCOPO6 NOT ACTIVE IST314I END -- 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
Emulator Sessions Hung
Greetings again, I've been trying to track down the cause of several emulator sessions not coming back alive after IPL's. We have two PC's running EXTRA! 3270 emulators. Each has four emulator sessions defined and running. When we IPL, one set of sessions on one PC come back alive just fine. Of the four sessions on the other PC, only one comes back alive. I double checked all the session definitions. They match. I had EXTRA! reloaded on the PC. I checked for weird things in TN3270 and VTAM, but find nothing to explain this inconsistent behavior. We can bounce the CICS regions these are defined to and they recover the sessions just fine. We only experience the connectivity issue after IPL's. Any ideas on what to check next -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 11:45:20 -0600, Kopischke, David G. dgkopisc...@oppenheimerfunds.com wrote: Any ideas on what to check next David, a couple of questions if I may. 1) Does the Extra session stay connected? 2) Is this a telnet session to port 23? 3) What is supposed to appear on the screen? A USSTAB? -- 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
Re: Emulator Sessions Hung
Did you check the time out or keep alive setting for the ones not working? From: Kopischke, David G. dgkopisc...@oppenheimerfunds.com To: IBM-MAIN@bama.ua.edu Date: 06/18/2010 12:45 PM Subject:Emulator Sessions Hung Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Greetings again, I've been trying to track down the cause of several emulator sessions not coming back alive after IPL's. We have two PC's running EXTRA! 3270 emulators. Each has four emulator sessions defined and running. When we IPL, one set of sessions on one PC come back alive just fine. Of the four sessions on the other PC, only one comes back alive. I double checked all the session definitions. They match. I had EXTRA! reloaded on the PC. I checked for weird things in TN3270 and VTAM, but find nothing to explain this inconsistent behavior. We can bounce the CICS regions these are defined to and they recover the sessions just fine. We only experience the connectivity issue after IPL's. Any ideas on what to check next -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- 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 -- 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
Re: Emulator Sessions Hung
All PD starts with an error message or error code. Please check the SYSLOG at IPL time, the VTAM log, and the CICS MSGLOG. Either there is an error message for these 3 devices in one or more of these logs or not. If there is, it will tell us where to start PD. If there is not, then VTAM and CICS are not even trying to connect at IPL time and PD will go down that path. But without an error message or the positive lack thereof, we are just guessing, speculating, shooting in the dark, because it could anyone of number of things. On Fri, Jun 18, 2010 at 2:26 PM, Michael Saraco michael.sar...@baer-consulting.com wrote: Did you check the time out or keep alive setting for the ones not working? From: Kopischke, David G. dgkopisc...@oppenheimerfunds.com To: IBM-MAIN@bama.ua.edu Date: 06/18/2010 12:45 PM Subject:Emulator Sessions Hung Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Greetings again, I've been trying to track down the cause of several emulator sessions not coming back alive after IPL's. We have two PC's running EXTRA! 3270 emulators. Each has four emulator sessions defined and running. When we IPL, one set of sessions on one PC come back alive just fine. Of the four sessions on the other PC, only one comes back alive. I double checked all the session definitions. They match. I had EXTRA! reloaded on the PC. I checked for weird things in TN3270 and VTAM, but find nothing to explain this inconsistent behavior. We can bounce the CICS regions these are defined to and they recover the sessions just fine. We only experience the connectivity issue after IPL's. Any ideas on what to check next -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- 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 -- 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 -- George Henke (C) 845 401 5614 -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 13:13:03 -0500, Patrick Lyon ptl...@midamerican.com wrote: David, a couple of questions if I may. 1) Does the Extra session stay connected? 2) Is this a telnet session to port 23? 3) What is supposed to appear on the screen? A USSTAB? 1) The EXTRA! session stays running on the PC. Connectivity to the host is lost. 2) Yes. 3) Yes. -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 13:26:00 -0500, Michael Saraco michael.sar...@baer- CONSULTING.COM wrote: Did you check the time out or keep alive setting for the ones not working? Yes, TN3270 has both these PC's IP addresses listed as KEEPALIVE. -- 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
Re: Emulator Sessions Hung
My (non attachmate) emulator has a keepalive setup option. Did you compare the settings for each of the emulators you're having trouble with compared to an emulator that is working OK? From your reply (below), it sounded like you were talking about z/OS TN3270 options, not emulator options. Brian On Fri, 18 Jun 2010 14:40:59 -0500, Dave Kopischke wrote: On Fri, 18 Jun 2010 13:26:00 -0500, Michael Saraco wrote: Did you check the time out or keep alive setting for the ones not working? Yes, TN3270 has both these PC's IP addresses listed as KEEPALIVE. -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 14:40:16 -0400, George Henke gahe...@gmail.com wrote: All PD starts with an error message or error code. Please check the SYSLOG at IPL time, the VTAM log, and the CICS MSGLOG. I didn't notice these in my first pass IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTOLD REAL DLU=SSINET.PCOPO3 IST889I SID = D5DBA179299B6BFD IST264I REQUIRED RESOURCE PCOPO3 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO5 IST889I SID = D5DBA179299B6BF6 IST264I REQUIRED RESOURCE PCOPO5 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO6 IST889I SID = D5DBA179299B6BF7 IST264I REQUIRED RESOURCE PCOPO6 NOT ACTIVE IST314I END -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 14:58:38 -0500, Brian Peterson brian.peterson.ibm.m...@comcast.net wrote: My (non attachmate) emulator has a keepalive setup option. Did you compare the settings for each of the emulators you're having trouble with compared to an emulator that is working OK? From your reply (below), it sounded like you were talking about z/OS TN3270 options, not emulator options. I have checked everything obvious. The EXTRA! definitions of the sessions all match except for LU name. I didn't see a KEEPALIVE option in those definitions though. No timeout or anything like that either. -- 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
Re: Emulator Sessions Hung
Thank you Dave, this is a good start. The 08570003 means the VTAM Secondary LU is not active. According to QUICKREF(QW): o If the required resource is NOT ACTIVE, enter a VARY ACT command to activate the resource. If the resource is an application program, start it. Are you issuing a VARY ACT manually after the IPL to get these sessions active? If not, somehow they are getting started because I believe you said they eventually go into session. You need simply to look further into these logs to see at what point these LU's become active and who finally activates them, how are they activated.. The Attachmate emulator program is known as an application LU, not a physical 3270 LU. But VTAM does not know the difference. So if for some reason the Attachmate emulator program is not started in the PC at the time VTAM issues the INIT BIND for it, it will look to VTAM like the physical terminal is turned off. You could check for any anomalies, like pauses, in the Attachmate script that starts the emulator programs. But, this would still just be guessing because we need to research further in the logs to see at what point the LU's finally come active and how they are activated. It could be by an operator manually, could be NETVIEW scripts, could be CICS AUTOINSTALL, could be a VTAM MAJNODE not being active. It is all still to soon to draw conclusions without more information. So, please continue to examine the logs: SYSLOG, VTAMLOG, and CICS MSGLOG, to spot the precise point at which these SLU's become active and who is doing it. On Fri, Jun 18, 2010 at 3:59 PM, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 14:40:16 -0400, George Henke gahe...@gmail.com wrote: All PD starts with an error message or error code. Please check the SYSLOG at IPL time, the VTAM log, and the CICS MSGLOG. I didn't notice these in my first pass IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTOLD REAL DLU=SSINET.PCOPO3 IST889I SID = D5DBA179299B6BFD IST264I REQUIRED RESOURCE PCOPO3 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO5 IST889I SID = D5DBA179299B6BF6 IST264I REQUIRED RESOURCE PCOPO5 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO6 IST889I SID = D5DBA179299B6BF7 IST264I REQUIRED RESOURCE PCOPO6 NOT ACTIVE IST314I END -- 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 -- George Henke (C) 845 401 5614 -- 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
Re: Emulator Sessions Hung
Dave I have checked everything obvious. Everything obvious includes particularly any error messages. My first reaction to George Henke suggesting that you look for error messages was What nonsense, of course he checked for error messages, grandmothers are very good at doing something I have had intellectually challenged list/forum moderators object to[1] to eggs! Imagine my surprise when - lo and behold - it turns out there were some error messages to be perused/pursued! IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTOLD REAL DLU=SSINET.PCOPO3 IST889I SID = D5DBA179299B6BFD IST264I REQUIRED RESOURCE PCOPO3 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO5 IST889I SID = D5DBA179299B6BF6 IST264I REQUIRED RESOURCE PCOPO5 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO6 IST889I SID = D5DBA179299B6BF7 IST264I REQUIRED RESOURCE PCOPO6 NOT ACTIVE IST314I END So what do you make of sense code 08570003? Pause while you look it up ... Now just to be sure we are reading from the same hymn sheet[2]. What are TESTOLD and TESTTRN? I'm going to guess they are some sort of application. I'm also going to guess that you have deceived yourself and us in that you do *not* expect to see an USS message 10 appear but you expect to log onto a CICS system named either TESTOLD or TESTTRN. I can see no point otherwise in your mentioning that you checked for CICS messages. You need to explain why there is a session setup attempt which discovers that the secondary LU is inactive at the time the session setup is attempted. What you appear to have is some sort of timing problem while system components are being brought up such that not all the resources necessary to be active are active at the right time and there is no recovery from a failure. Please be very precise about exactly how you - or a colleague who was responsible - have configured your emulator, the TN3270 server, the APPL statements representing the secondary LUs and TESTOLD/TESTTRN as it affects the establishment of a connection and session. Chris Mason [1] An amusing sequence introducing the film Getting Straight is a student protesting over something holding a placard stating Gravity is a lie on one side and The Earth that word to which moderators may object on the other. [2] From the z/OS Communications Server IP and SNA Codes manual - which you should always have logically/electronically to hand: quote Sense code 0857 SSCP-LU Session Not Active: The SSCP-LU session, required for the processing of a request, is not active; for example, in processing REQECHO, the SSCP did not have an active session with the target LU named in the REQECHO RU. Bytes 2 and 3 following the sense code contain sense-code-specific information. ... 0003 The SSCP-SLU session is inactive. /quote On Fri, 18 Jun 2010 15:01:46 -0500, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 14:58:38 -0500, Brian Peterson brian.peterson.ibm.m...@comcast.net wrote: My (non attachmate) emulator has a keepalive setup option. Did you compare the settings for each of the emulators you're having trouble with compared to an emulator that is working OK? From your reply (below), it sounded like you were talking about z/OS TN3270 options, not emulator options. I have checked everything obvious. The EXTRA! definitions of the sessions all match except for LU name. I didn't see a KEEPALIVE option in those definitions though. No timeout or anything like that either. -- 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
Re: Emulator Sessions Hung
Everything obvious includes particularly any error messages. My first reaction to George Henke suggesting that you look for error messages was What nonsense, of course he checked for error messages, grandmothers are very good at doing Sorry, sometimes it takes the naive to see the obvious. On Fri, Jun 18, 2010 at 5:28 PM, Chris Mason chrisma...@belgacom.netwrote: Dave I have checked everything obvious. Everything obvious includes particularly any error messages. My first reaction to George Henke suggesting that you look for error messages was What nonsense, of course he checked for error messages, grandmothers are very good at doing something I have had intellectually challenged list/forum moderators object to[1] to eggs! Imagine my surprise when - lo and behold - it turns out there were some error messages to be perused/pursued! IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTOLD REAL DLU=SSINET.PCOPO3 IST889I SID = D5DBA179299B6BFD IST264I REQUIRED RESOURCE PCOPO3 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO5 IST889I SID = D5DBA179299B6BF6 IST264I REQUIRED RESOURCE PCOPO5 NOT ACTIVE IST314I END IST663I INIT OTHER REQUEST FAILED, SENSE=08570003 IST664I REAL OLU=SSINET.TESTTRN REAL DLU=SSINET.PCOPO6 IST889I SID = D5DBA179299B6BF7 IST264I REQUIRED RESOURCE PCOPO6 NOT ACTIVE IST314I END So what do you make of sense code 08570003? Pause while you look it up ... Now just to be sure we are reading from the same hymn sheet[2]. What are TESTOLD and TESTTRN? I'm going to guess they are some sort of application. I'm also going to guess that you have deceived yourself and us in that you do *not* expect to see an USS message 10 appear but you expect to log onto a CICS system named either TESTOLD or TESTTRN. I can see no point otherwise in your mentioning that you checked for CICS messages. You need to explain why there is a session setup attempt which discovers that the secondary LU is inactive at the time the session setup is attempted. What you appear to have is some sort of timing problem while system components are being brought up such that not all the resources necessary to be active are active at the right time and there is no recovery from a failure. Please be very precise about exactly how you - or a colleague who was responsible - have configured your emulator, the TN3270 server, the APPL statements representing the secondary LUs and TESTOLD/TESTTRN as it affects the establishment of a connection and session. Chris Mason [1] An amusing sequence introducing the film Getting Straight is a student protesting over something holding a placard stating Gravity is a lie on one side and The Earth that word to which moderators may object on the other. [2] From the z/OS Communications Server IP and SNA Codes manual - which you should always have logically/electronically to hand: quote Sense code 0857 SSCP-LU Session Not Active: The SSCP-LU session, required for the processing of a request, is not active; for example, in processing REQECHO, the SSCP did not have an active session with the target LU named in the REQECHO RU. Bytes 2 and 3 following the sense code contain sense-code-specific information. ... 0003 The SSCP-SLU session is inactive. /quote On Fri, 18 Jun 2010 15:01:46 -0500, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 14:58:38 -0500, Brian Peterson brian.peterson.ibm.m...@comcast.net wrote: My (non attachmate) emulator has a keepalive setup option. Did you compare the settings for each of the emulators you're having trouble with compared to an emulator that is working OK? From your reply (below), it sounded like you were talking about z/OS TN3270 options, not emulator options. I have checked everything obvious. The EXTRA! definitions of the sessions all match except for LU name. I didn't see a KEEPALIVE option in those definitions though. No timeout or anything like that either. -- 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 -- George Henke (C) 845 401 5614 -- 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
Re: Emulator Sessions Hung
On Fri, 18 Jun 2010 16:43:13 -0400, George Henke gahe...@gmail.com wrote: Thank you Dave, this is a good start. The 08570003 means the VTAM Secondary LU is not active. Are you issuing a VARY ACT manually after the IPL to get these sessions active? No, I don't see anything varying them active. Neither the ones that work nor the ones that don't. If not, somehow they are getting started because I believe you said they eventually go into session. The operators manually restart the EXTRA sessions. Once they do that, they get the VTAM splash and connect up just fine. So if for some reason the Attachmate emulator program is not started in the PC at the time VTAM issues the INIT BIND for it, it will look to VTAM like the physical terminal is turned off. The PC and emulator sessions remain on throughout the IPL. Once VTAM initializes, all the emulators get the VTAM splash and work as expected except for these three. It could be by an operator manually, could be NETVIEW scripts, could be CICS AUTOINSTALL, could be a VTAM MAJNODE not being active. That's why I posted. I checked everything I could think of (everything obvious). I'll look through VTAM messages more closely and see if there's something buried deeper in there. I already checked AUTOINSTALL and found no differences, but I'll look at that again. There has to be an answer. -- 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
Re: Emulator Sessions Hung
Thank you, Dave, this is very helpful. I would switch the focus now to the one good Attachmate session on the PC which works. Please trace it through the IPL SYSLOG and note where and how it is activated and how it goes into session. Note its majnode, timing, etc. Then without losing your focus, note, as you go along, any irregularities occurring with the other 3 failing nodes at or about the same time. I know this may sound super simple but in PD, whenever you have an instance where something works and something is broken, the solution is simple and sure if you just remember to always work from the side that works first. Then you will eventually see and find what is going wrong with the other one that is broken. The big mistake most people make is to get stuck on the broken one and ignore the one good one that is working. That approach never leads anywhere. So please go back through the IPL SYSLOG and this time track the one good node that is working and let us know what you find. On Fri, Jun 18, 2010 at 6:12 PM, Dave Kopischke dgkopisc...@oppenheimerfunds.com wrote: On Fri, 18 Jun 2010 16:43:13 -0400, George Henke gahe...@gmail.com wrote: Thank you Dave, this is a good start. The 08570003 means the VTAM Secondary LU is not active. Are you issuing a VARY ACT manually after the IPL to get these sessions active? No, I don't see anything varying them active. Neither the ones that work nor the ones that don't. If not, somehow they are getting started because I believe you said they eventually go into session. The operators manually restart the EXTRA sessions. Once they do that, they get the VTAM splash and connect up just fine. So if for some reason the Attachmate emulator program is not started in the PC at the time VTAM issues the INIT BIND for it, it will look to VTAM like the physical terminal is turned off. The PC and emulator sessions remain on throughout the IPL. Once VTAM initializes, all the emulators get the VTAM splash and work as expected except for these three. It could be by an operator manually, could be NETVIEW scripts, could be CICS AUTOINSTALL, could be a VTAM MAJNODE not being active. That's why I posted. I checked everything I could think of (everything obvious). I'll look through VTAM messages more closely and see if there's something buried deeper in there. I already checked AUTOINSTALL and found no differences, but I'll look at that again. There has to be an answer. -- 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 -- George Henke (C) 845 401 5614 -- 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
Re: Emulator Sessions Hung
On 6/18/2010 5:13 PM, Dave Kopischke wrote: That's why I posted. I checked everything I could think of (everything obvious). I'll look through VTAM messages more closely and see if there's something buried deeper in there. I already checked AUTOINSTALL and found no differences, but I'll look at that again. There has to be an answer. Have you checked the definitions in VTAMLST to make sure they don't specify LOGAPPL=xxx This will also show up on a D NET,ID=terminalluname,E as CONTROLLING LU = applid -- Richard -- 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
Re: Emulator Sessions Hung
Richard's suggestion does fit the crime. On Fri, Jun 18, 2010 at 7:18 PM, Richard Peurifoy r-peuri...@neo.tamu.eduwrote: On 6/18/2010 5:13 PM, Dave Kopischke wrote: That's why I posted. I checked everything I could think of (everything obvious). I'll look through VTAM messages more closely and see if there's something buried deeper in there. I already checked AUTOINSTALL and found no differences, but I'll look at that again. There has to be an answer. Have you checked the definitions in VTAMLST to make sure they don't specify LOGAPPL=xxx This will also show up on a D NET,ID=terminalluname,E as CONTROLLING LU = applid -- Richard -- 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 -- George Henke (C) 845 401 5614 -- 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
Re: Emulator Sessions Hung
I would try Richard's suggestion first. On Fri, Jun 18, 2010 at 7:28 PM, George Henke gahe...@gmail.com wrote: Richard's suggestion does fit the crime. On Fri, Jun 18, 2010 at 7:18 PM, Richard Peurifoy r-peuri...@neo.tamu.edu wrote: On 6/18/2010 5:13 PM, Dave Kopischke wrote: That's why I posted. I checked everything I could think of (everything obvious). I'll look through VTAM messages more closely and see if there's something buried deeper in there. I already checked AUTOINSTALL and found no differences, but I'll look at that again. There has to be an answer. Have you checked the definitions in VTAMLST to make sure they don't specify LOGAPPL=xxx This will also show up on a D NET,ID=terminalluname,E as CONTROLLING LU = applid -- Richard -- 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 -- George Henke (C) 845 401 5614 -- George Henke (C) 845 401 5614 -- 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
