>> ... 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
