>>snip 1) FTPD gets a connection request on port 21. 2) FTPD sets up the socket. 3) FTPD does a fork(), which is what starts up the BPXAS address space and usually calls it FTPDn (1<= n <= 9) 4) FTPDn prompts for the user and password. 5) FTPDn then validates that and changes its RACF id (and UNIX identity) if they are valid. 6) FTPDn then prompts for and executes the user's commands until the client quits.
>>end snip The problem address spaces do not change name from BPXAS. When we had an outage, we had over 390 such address spaces. A little experimentation: 5 BPXAS address spaces are waiting. I connect to FTP from my PC. No new address spaces. Netstat shows my workstation has a connection to the FTPD1 address space on port 21. I sign on. The name of one of the BPXAS address spaces changes to be my userid. The TCP/IP session is still with FTPD1. I enter 'QUIT' on the FTP session. The workstation terminates FTP, and the address space on the on the mainframe is renamed to BPXAS again. I can verify that the BPXAS address space is processing the signon request, because when I enter an invalid password, the error message comes from one of the BPXAS address spaces. What this indicates to me is that FTPD1 manages the port for the control session, and passes messages to and from the BPXAS address space. This still leaves me with the main problem. Numerous BPXAS address spaces can be created in a short time, resulting in an address space shortage. the address spaces will stick around until they reach the SMF wait time limit. I have documented as many as 90 such address spaces being created in just 60 seconds. I do not, however, see that any user signed onto those sessions, so the BPXAS address spaces are just waiting for userid/password or something else. ---------------------------------------------------------------------- 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
