#142 FNP "not accepting calls" logic incorrect.
https://github.com/charlesUnixPro/dps8m/issues/3
MakeItGreatAgain commented 6
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 commented 6 days 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.
Test fix for master in branch master_tckt_142, commit 2fd9da4.
rc11 fix is on rc11 branch; commit 6c86cde