charlesUnixPro
commented
6 years ago The message "Multics is not accepting calls" is a local feature. The code that generates the message has no way of telling if a user is logged in or not.
Looking at the FNP emulation code, it is probably just wrong; I looks like it is incorrectly blocking logged on users.
I suspect that the documentation is misleading; "logged on" should be "connected". The stop_mpx command should stop the FNP from answering the phone, as it is unable to distinguish between an answered phone line and a logged in phone line.
The checks of MState.accept_calls and linep->listen and the associated message and "return"s should be deleted from processLineInput() and process3270Input().
processUserInput() should be reworked so as not to attach lines when MState.accept_calls is set. This a little tricky; it is not Multics that is not answering, it is a particular FNP. processUserInput() prompts for a line number, and needs to check that the FNP for the requested line is accepting calls and that the particular line is listening; if all is good, it should make the association, else report the problem ("FNPx not accepting" or "x.xnnn not listening" and reprompt. The prompt code should check each FNPs accept_calls state before listing its lines.
These changes should prevent answered lines from being affected by stop_mpx, and will stop the FNP from generating an answer event in response to telnet connections; the connection will be left up, and terminal activity generating the "not accepting" message until FNP is set to allow answering.
The documentation states "Users currently logged in over the multiplexer channels are not affected", but issuing the stop_mpx command causes channels both with and without user logins to immediately return "Multics is not accepting calls".
Not a high priority problem but still a deviation from the documentation.