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 >soooooo 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.net>wrote: > >> 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 >> parameters. >> >> I then scanned the "Open Systems Adapter-Express Integrated Console >> Controller Users Guide" manual for "KEEPALIVE" without a hit. >> >> So what is this all about? What "TN3270" are we talking about here? Is >> the "KEEPALIVE" to which Dave Kopischke is referring the same "KEEPALIVE" >> to >> which Michael Saraco is referring? Perhaps Michael Saraco had in mind >> some "KEEPALIVE" in the emulator customisation which would be a mystery to >> me since I think I have tried unsuccessfully to find EXTRA manuals before. >> This incidentally was the only way Brian Peterson could make any sort of >> sense of "KEEPALIVE" and the answer to this had me on the verge of tears >> ... >> >> - >> >> From the post of "Fri 17:12:48 -0500" as a result of questions from George >> Henke: >> >> - It is confirmed that the communication to the USS message 10 or CICS - >> whichever it is supposed to be although the peculiar terminology inclines >> us to >> an USS message 10 - is achieved by the operator at the 3270 emulator >> window rather than happening automatically following the IPL. If it didn't >> before the problem starts to "smell" of timing. Of course, I have to assume >> this >> peculiar terminology "VTAM splash" refers to an USS message 10.[2 again!] >> >> - Since the communication is supposed to be established automatically, talk >> of >> entering VARY commands is a "red herring". >> >> - Ha - the water is muddied once more and CICS tries to gain the ascendancy >> over the USS message 10 in all this talk of the "autoinstall" function. I >> suppose >> it is understood that, if you expect to achieve communication between a >> TN3270 client 3270 emulator and a TN3270 server such that the USS message >> 10 appears, you have got nowhere near any CICS application. I'm scratching >> my head over the extent to which you have got near VTAM. I think a VTAM >> APPL statement will have been allocated to the TN3270 connection and maybe >> the ACB opened but it won't really be "used" until an USS command is >> entered >> in the attempt to set up a session. >> >> - >> >> From the post of "Fri 14:59:45 -0500" as a result of questions from George >> Henke: >> >> - There are messages which indicate that there are three session setups >> which fail because the secondary LUs, PCOPO3, PCOPO5 and PCOPO6 are not >> active. Since these LUs are not active whatever caused the session setup >> cannot be related to the activation of the VTAM definition related to these >> LUs. I would have thought that meant it could not be a LOGAPPL operand - >> but I may be about to learn something. >> >> - >> >> That QUICKREF text you found is potentially very helpful. If the TN3270 >> server >> is the z/OS Communications Server TN3270E server, "starting the >> application" >> corresponds - I think - to a TN3270 TCP connection being set up. >> >> It's actually not worth anyone bothering with this any more until Dave >> Kopischke deigns to respond to my questions and specifically mentions what >> his TN3270 server is and what definitions are associated with it which >> relate >> to setting up an SNA session to CICS and which CICS, TESTOLD, TESTTRN or >> other - or not as the case may be. >> >> -- >> >> Incidentally, if the z/OS Communications Server TN3270E server is being >> used, >> we should hear some discussion of the use of the DEFAULTAPPL statement or >> a LUMAP statement DEFAPPL parameter should we not? - perhaps controlled >> by some "client identifier" since it appears that more than one "default >> application" is desired. >> >> Come to think of it, this tends to suggest that the TN3270 server might >> actually be the OSA-ICC. In this case, despite all this confusing talk of >> USS >> message 10 being expected, perhaps LOGAPPL is being used, a session setup >> attempt is being initiated at the time the CICS applications open their >> ACBs or >> the major node containing the LOCAL statements is activated. Maybe there is >> no logical SSCP-SLU session if the pre/non-SNA channel-attached device >> channel programs show no device is connected which would correspond to no >> TN3270 TCP connection yet having been established. Could the order of >> members in the ATCCONxx member be relevant? >> >> Is this still a puzzle? It's not clear what the operators need to in order >> to >> achieve their objective. I don't trust this talk about "VTAM splash". It >> may be >> actually a "CICS splash". All this would mean is that the session setup >> between the LU represented by the LOCAL statement and the LU represented >> by the application failed during IPL because of timing and that the >> operators >> compensate for the failed LOGAPPL. >> >> As I said, probably it's a waste of time trying to speculate further. >> However, >> while puzzling over the possibility that an OSA-ICC could be the TN3270 >> server, I checked the redbook "OSA-Express Integrated Console Controller >> Implementation Guide" and found "4.2.2 Display PCOMM host connection log" >> which looks like another possibly handy source of information - and, if an >> OSA- >> ICC is the TN3270 server, an *obvious* one! >> >> -- >> >> Chris Mason >> >> [1] As, for example, in the case of the OSA-ICC, which supports >> TN3270 "connections" and has nothing whatsoever at all in this world to do >> with SNA sessions. You just need to focus on whet the principle purpose for >> which the ICC was conceived to appreciate that!!! >> >> [2] It's the trouble with approximate descriptions that they increase the >> always present opportunity to be misunderstood. That's why I'm something of >> a stickler for accuracy since it minimises - never eliminates of course - >> the >> possibility of misunderstanding. >> >> >> On Fri, 18 Jun 2010 17:38:04 -0400, George Henke <gahe...@gmail.com> >> wrote: >> >> >"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.net>wrote: >> > >> >> Dave >> >> >> >> > I have checked everything obvious. >> >> >> >> ... ---------------------------------------------------------------------- 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
