CAC 2016-02-03


was looking at the Kermit fail; I dumped all of the Multics/DPS8 transactions, on the theory that the Multics kermit server was invoking an unimplemented function, and that was the root of the issue.

We see:

fnp_command("fnp-d", "cpu-a", "set_framing_chars 0 0 3")^M
fnp_command("fnp-d", "cpu-a", "eight_bit_out 0 1")^M
fnp_command("fnp-d", "cpu-a", "block_xfer 0 96 96")^M
fnp_command("fnp-d", "cpu-a", "echoplex 0 0")^M
fnp_command("fnp-d", "cpu-a", "lfecho 0 0")^M
fnp_command("fnp-d", "cpu-a", "set_delay_table 0 0 0 0 0 0 0")^M
fnp_command("fnp-d", "cpu-a", "dump_input 0")^M

eight_bit_out is ignored by the FNP, it always does 8 bit xfer.

echoplex, lfecho and dump_input are supported.

set_delay_table is ignored — it your terminal can't get the cursor to the 1st column quickly, you'll see problems.

This leaves set_framing_chars and block_xfer, which are ignored due to no documentation.

"Set Framing Characters (010)
    Purpose: Provide that frame_begin and frame_end characters to be recognized when in blk_xfer mode.

    Associated Data:
       Word 2: bits 0..8 contain the frame_begin character.
       Word 2: bits 9..17 contain the frame_end character."

So "set_framing_chars 0 0 3" sets line 0 frame_begin to 0 (NUL) and frame_end to 3 (^C). Easy enough.

Note, however, that the kermit client doesn't send NUL or ^C characters, so 'framing' is not occurring.

"Block Transfer (031)
  Additional Data: 
    Word 2: Bits 18...35 contain the size, in characters, of each input buffer to be used when not within a frame.
    Word 3: Bits 0...17 contain the size, in characters, of each input buffer to be used within a frame."

CC92 Comm IO, pp 2-20, 2-21 discuss block transfer; the idea seems to be that some terminals can buffer up input and send it in a blast; the FNP block transfer command pre-allocates buffers to prevent overrun. (Obviously, kermit will send data at line speed, so preventing overrun is sensible). It talks about "frame begin not set", which I assume is what setting it to NUL means; if it is not set, then the frame end character suffices to define a frame, and "In general, none of the characters in a frame are delivered to the user's process until the end of the frame has benn reached. Calls to iox_$get_line still rad input one line at a time, but the first line in a frame is not available for reading until the entire frame has been received."

Mutics kermit uses timed_io_$get_chars; given that the client kermit never sends a frame_end character, I don't see offhand how ignoring the block transfer mode, and just delivering incoming data line by line could cause problems.

Did some logging of I/O


msg: kermit is in receive()
client sends "kermit -ir"
client sends "9 S~/ @-#Y3~^>J)0___^"U1@W    013920537e2f20402d2359337e5e3e4a29305f5f5f5e22553140570a
clinet sends "9 S~/ @-#Y3~^>J)0___^"U1@W     013920537e2f20402d2359337e5e3e4a29305f5f5f5e22553140570a
msg: kermit receives: 9 S~/ @-#Y3~^>J)0___^"U1@W

msg: kermit is in receive()
client sends ")!FTEST.C""   01292146544553542e43220a
client sends ")!FTEST.C""   01292146544553542e43220a
msg: kermit receives: !FTEST.C"

msg: kermit is in receive()
client sends:  "D!#-##include <string.h>#M#Jsize_t foo (char * buf)#M#J  {#M#J~$ return strspn (buf, ":");#M#J  }#M#JX    0120224421232d2323696e636c756465203c737472696e672e683e234d234a73697a655f7420666f6f202863686172202a2062756629234d234a20207b234d234a7e242072657475726e2073747273706e20286275662c20223a22293b234d234a20207d234d234a580a
msg: kermit receives: D!#-##include <string.h>#M#Jsize_t foo (char * buf)#M#J  {#M#J~$ return strspn (buf, ":");#M#J  }#M#JX

It looks like data is going into Multics but not making it to the application; I wonder if block xfer mode needs to pad lines out to the block length?

'wdc invoke' does not set block xfer mode, so is not directly related.

tried removing blk_xfer mode set from kermit; didn't seem to help.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License