Hum... Let me noodle over that for a bit.
I think it's a completely reasonable position to assume that I've
a mistake, wrong assumption or am using something in such a way
that it does not want to be used... After all, the code is brand
new; just written, Etc.
I'll have to put some more instrumentation in, Etc, Etc.
I don't imagine there is anything clever about MIM::DU1:[DECNET]TEST.DIS;1?
Don't see why there would be...
On 11/29/22 7:09 PM, Johnny Billquist wrote:
What I can tell is what I can see in the sources. And there I have this:
HF.STR=001 ; Stream ID bit in DAP header menu
HF.LEN=002 ; Length bit in DAP header menu
HF.XLN=004 ; Extended length bit in DAP header menu
HF.BIT=010 ; BITCNT bit in DAP header menu
HF.SYS=040 ; System specific field bit in DAP header menu
HF.SEG=100 ; Segmented msg bit in DAP header menu
HT.BIT is the thing you are seeing which is not there in the DAP 5.6 spec. I don't really know what it is about, but it's something the RSX DAP have defined anyway.
I can't find any use of it. Looking in the code, I don't even see that it would ever be set. So I wonder if you made some mistake in your decoding?
Johnny
On 2022-11-29 18:41, Thomas DeBellis wrote:
I fixed the bit definition for Not Last Message of Segmented Message from bit 4 to 6 as per DAP V5.6 and properly defined bit 4 as the Reserved field. In other words, I am following Tops-10, which I believe to have the correct definitions. Then I finished the flag breakout logic and tested again some systems. The MIM:: result is of note, viz.:
[Parsing Name message] [Parsing Attributes message] [Allocated Receive buffer (Words=531. Len=2086.)] [Trimmed 381. words from receive buffer] [Received Date/time Attributes message (Flg=*RESV*,SYSPEC UFlg=1000 Cnt=560.)] [Parsing Date/time Attributes message] [Parsing File Protection Attributes message] [Parsing Name message] TEST.DIS;1;P775656 2 2560(8) 18-Nov-2013 01:18:27So what's up with *RESV*? Is (reserved) bit 4 being used for something new (I.E., post DAP 5.6) now? If so, what? The UFlg is an octal field for bits that I don't know about. In this case, MIM:: is sending bit 9 high, which the PDP-10 (which is the opposite endian) sees as bit 26. What's that?
Just wondering if I'm seeing what I'm seeing here...
On 11/27/22 12:34 AM, Thomas DeBellis wrote:
Whoops, I mistyped the PDP-10 bit definition for bit six; it's 1B*29* and not 1B/28/. Sigh...
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B29
I looked the Tops-10 DAP flags definitions (in SWIL.MAC); it looks like Tops-10 has it right and Tops-20 has it wrong, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream ID field present 1B35 DF$SID
1 LENGTH field present 1B34 DF$HLN
2 LEN256 field present 1B33 DF$HL2
3 BITCNT field present 1B32 DF$BCT
*4* *Reserved* *1B31* *DF$XX1*
5 SYSPEC field present 1B30 DF$SHX
*6* *More data coming* *1B29* *DF$MOR*
Johnny, can you send me the RSX DAP flag definitions when you get a minute?
On 11/26/22 11:58 PM, Thomas DeBellis wrote:
I was writing a routine to break out DAP flag bits to aid debugging when I noticed a possible discrepancy between DAP V5.6 and Tops-20, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B28
DAP V5.6 reserves bit 4 and defines bit 6 to flag that a segmented message is being sent and that this is not the last message. In other words, that there will be another message. Tops-20 is using bit 4 for this purpose and by rights it would appear that it should be using bit 6.
I will go see if I can't scare up what Tops-10 is doing, but I was wondering if anyone knew what other OS's are doing.