Barbara Thanks for the points about the Communications Server (CS) IP component - yes that's your TCPIP address space(s) - and their dependency on UNIX System Services. Tom Russell emphasis the API but I also remembered the Resolver address space and INET/CINET.
Regarding your problems with your TCPTNx address spaces: I hope this is all to do with TN3270 address spaces and nothing to do with otelnetd. It may be my total unfamiliarity with otelnetd in practice that makes this a stupid question. However you always refer to TELNET and not TN3270 - or TN3270E. I see you had difficulty getting the address spaces to disappear. This reminded me of something about which I vaguely remember discussing before that involved the following text in the CS IP Configuration Guide in section "Steps for starting the TN3270E Telnet server", step 8, "Start Telnet by issuing START tnproc, where tnproc is the Telnet procedure member name." <quote> Tips: - ... - The default MVS program properties table (PPT) entry sets Telnet to be a non-cancelable application. As a non-cancelable application, a TCP/IP stack should not automatically start Telnet using the AUTOLOG function. If the TCP/IP stack is recycled, the stack tries to cancel and restart all AUTOLOG applications. A non-cancelable application does not end and the following messages are issued repeatedly: N 0140000 SA6I 2005147 04:59:27.69 STC07087 00000084 EZZ0621I AUTOLOG FORCING IBMTNSI0, REASON: TCP/IP HAS BEEN RESTARTED NR0000000 SA6I 2005147 04:59:27.71 STC07087 00000080 IEE838I IBMTNSI0 NON-CANCELABLE - ISSUE FORCE ARM ... - ... </quote> Perhaps you really don't need the TN3270 address space to be "non- cancelable" and so you could set up a SCHEDxx member PPT entry which mimics the supplied entry but removes the "non-cancelable" attribute. With the "non-cancelable" attribute removed, you can specify your TN3270 started task procedure in the AUTOLOG list and have it handled just like all the other servers. In the extremely unlikely event that you are unfamiliar with how to do this, it's all in Chapter 67-0 of the MVS Initialization and Tuning Reference. I used to do this sort of thing with the SYST attribute and suffered no harmful effects. In fact I gained function - but that's another story! Note that all this relates to the main CS IP address space starting and stopping and is not related to the OMVS address space stopping and starting. That's the one that is causing you grief. Chris Mason On Thu, 6 Aug 2009 00:44:20 -0500, Barbara Nitz <[email protected]> wrote: >>> ... TCPIP is a UNIX based application. >> >>Not really. UNIX System Services has got involved with the Communications >>Server (CS) IP component over the years and, I expect, will into the future. >>However, it started before UNIX System Services and its predecessors >>appeared - or perhaps about the same time but was completely independent. >>Consequently, I expect you could run CS IP and have nothing to do with >>anything touched by UNIX System Services. Can anybody still reading verify >>this? > >Keep in mind that I am *not* very good with TCPIP and/or OMVS services. >Recent experience has shown (and resulted in *a lot* of ETRs) that TCPIP >cannot exist without the OMVS address space (and at this point I feel >sufficiently chastized :-) NOT to use the word USS services). So that makes >the sentence 'TCPIP is a UNIX based application' sort of true if UNIX stands >for 'OMVS services on z/OS'. > >As a last resort for a semi-productive system we tried F OMVS,SHUTDOWN in >a test system, in full flight, without shutting down *anything* dependent on >OMVS (mostly because it is unclear *what* depends on OMVS these days). >What I expected was that everything dependent on OMVS would come down >(more or less gracefully). > >All three of our TCPIP address spaces (three stacks) came down complaining, >but they did come down. In the process they wanted to write transaction >dumps using the wrong HLQ, so we did not get any of those dumps. That kinda >proves to me that TCPIP cannot live on z/OS these days without OMVS >services being available (and assuming CS IP is meaning TCPIP). > >What did NOT come down were the three corresponding telnet address spaces >(TCPTNx they're called here). Two of them made OMVS spit out a BPX >message that shutdown was aborted because TCPTNx was blocking it, but the >things did not react to stop commands anymore, cancel resulted in 'use force >arm', and force arm didn't work, either. A good old FORCE was necessary. The >third TCPTNx stayed up through OMVS shutdown and restart, but was >completely broken afterwards, resulting in an IPL. > >And *now* IBM is wringing their collective hands telling me that TCPTNx >is 'working as designed' (because the books say so, never mind that the books >do NOT show the reality) and have accepted a 'requirement' that the telnet >things should come down one way or another. They do NOT acknowledge that >the functionality they accepted the requirement for is already in the code, but >badly broken. I am still getting the 'this will be fixed in a later release'. > >The hints about developers being busy with other stuff and/or laid off make me >think that IBM has stripped itself also in this area of the necessary manpower, >a story I heard quite often in the last months! > >Best regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
