Open JimAllen256 opened 3 weeks ago
Sorry for the delay, I've been out of town.
I think that location 0x114a in the Andrews C00 system is known to DELTA as COD:HWL or maybe COD:HWL1. The C00 code in P2COC has some comments that reference COD:HWL. I think this is data is generated by pass2. It is not defined in the C00 load map.
I'd have to dig around with DELTA to find the F00 address.
The F00 code for P2COC is a little different in this area. Maybe that's the cause of the problem.
Is this important to you?
I'd be most interested in what you are doing with CPV as there is very little other interest in it and I'd like to get a little gratification from my work on it. ;-) I'd be happy to work on this if you think its important. kdrhoo at yahoo dot com
Ken
oops I didn't intend to close this
PM sent with background. In a nutshell, if you open a terminal session to CP-V and leave the telnet session open until CP-V times out the time sharing session, a "timed out" message is issued, the telnet session is disconnected and everything is fine. However, if you terminate the telnet session and CP-V subsequently times out the session and attempts to issue a "timed out" message, the line get hung somewhere between the COC code and the SIMH MUX. As a result, the MUX thinks the line is available and directs later telnet connections to that "line" but CP-V doesn't respond -- the session is hung with a blank screen.
After the CPU = .nnn etc text appears following a telnet time sharing session sign off, a logon prompt is generated:
CPU = .0000 CON= 00:00:00 INT = 6 CHG = 0
HONEYWELL CP-V AT YOUR SERVICE - SIMH 12:20 OCT 08,'90 USER# B LINE# 0 LOGON PLEASE:
Note that although no one has signed in, a user number (B) has been assigned to the uninitiated session. That new session will time out properly if the telnet session is left open until the OTLO time-out expires. The session can also be terminated by the operator issuing an !ABORT B command and the telnet session will be closed properly.
If the telnet session is closed before time-out expires (for example, the user doesn't want to login again and terminates the telnet connection), the session will eventually time out, the user gets cancelled but the MUX line is left in an unusable state. It is as if CP-V doesn't recognize the disconnected state of the MUX line.
Another way to explain is that unless CP-V is able to issue the timeout message on an active telnet session, the termination process doesn't get completed and the line state is undefined.
If a subsequent connection is attempted through the MUX and gets allocated to that line, "Connected to the XDS Sigma simulator MUX device, line 0" is printed but no logon prompt or text appears. ESC sequences or CTL combinations do not produce any result -- the session is unresponsive.
It appears that the automatic logon prompt generated for non-hardwired terminals is producing the unsolicited logon prompt that occurs after signout. (and causes issues if the terminal session is disconnected before timeout occurs).
Installing the CPCP system which has hardwired terminals defined does not exhibit the issue which seems to confirm the cause.
The instructions for CPCP indicate that location 114a contains the hardwired line flags for the first 32 lines wherein 0=automatic (non-hardwired) and 1=hardwired. Those instructions (in the README.MD file in the f00 folder) indicate writing X'00000000' would set the lines to automatic mode -- so i would assume that X'FFFFFFFF' sets all to hardwired mode.
Are the hardwired line flags for F00 also located at 114a? If so, this would be a simpler fix than re-running the SYSGEN with COC definitions changed.