>... but I also remembered the Resolver address space and INET/CINET. Yes, and my abendb78 in resolver code (and subsequent 0C4 in BPXsomething) will both get fixed in BPX code:-)
>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 meant TN3270 asids. That's why I warned that I haven't got a clue about those address spaces. Actually, the B78 in resolver was caused by a wrong INETD restart and exposed when a collegue used telnet to get into OMVS. (In the ETR I added VT100 - my IPÜ guy told me so:-)) >I see you had difficulty getting the address spaces to disappear. <lots of info snipped> I just checked the sched members in use. Though none of the IP address spaces are set explicitly in the PPT, they do make themselves an entry in the PPT (shown by SHOWZOS): PGMNAME(EZBTCPIP) KEY(6) Nocancel Noswap Priv SYST Spref Lpref - Default PGMNAME(EZBREINI) KEY(6) Nocancel Noswap Priv SYST - Default PGMNAME(EZBTNINI) KEY(6) Nocancel Noswap Priv SYST - Default The problem was not really that I could not cancel them (I did issue the force arm instead). The problem was that they did not terminate in reaction to *any* shutdown command - no stop, no force arm. FORCE executes in master and bypasses all tcb resource managers that may have wanted to run but could not because the needed OMVS service wasn't available anymore (my guess). That's what I consider a BUG (and not WAD), as IBM tries to tell me. Best regards, Barbara ps: See? No USS in my post! :-) ---------------------------------------------------------------------- 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
