Simulated FNP stop_mpx behavior differs from expected, documented behavior.

[MakeItGreatAgain]

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.

[charlesUnixPro]

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.