------------------------------------------------------------------------
On 11/29/22 2:26 PM, Paul Koning wrote:
I'm trying to read your message alongside the DAP 5.6.0 spec and
getting absolutely nowhere. None of the terms you mention are in the
DAP spec. Can you describe what you're seeing in terms of the spec?
And/or include a (binary format) tcpdump protocol capture?
paul
------------------------------------------------------------------------
On Nov 29, 2022, at 12:41 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote
I fixed the bit definition forNot Last Message of Segmented
Messagefrom 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. TheMIM:: 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:27
So what's up with*RESV*? Is (reserved) bit 4 being used for something
new (I.E., post DAP 5.6) now? If so, what? TheUFlgis 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.
>
>
>
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se