My apologies; as I've said, this is not my normal area.  I'm just trying to keep the sparks from flying out of Tops-20 DAP, but I'm a Galaxy nurd; DECnet was somebody else's purview at Columbia.

It's a shame the final code as shipped for Tops-20 V7 wasn't fully productized.  At one point, they were really doing it right.  I mean really great.  The version 21 DECnet SWS Kit (BB-H348C-RM_1982) is just chock full of goodies to do regression testing and lots of additional documentation.  Highly recommended!  I'm going to run some of them at some point, they go against RSX, RSTS, Etc.

Having whined about that, let me see if I can't do a better job.  Here is a table with the exact correspondence between the language on page 16 of DAP V5.6, by column:

  1. The bit as defined in DAP V5.6,
  2. The DAP language that defines it,
  3. Some additional explanation from DAP V5.6 (or my interpretation  thereof),
  4. The corresponding PDP-10 bit,
  5. The Tops-10 symbol (which were all defined correctly),
  6. The Tops-20 symbol I am using in DAPLIB (some of which were incorrectly defined) and
  7. What I'm having DAPLIB print when in debugging mode for the PDP-10 bit


DAP
Bit		 DAP V5.6
Language		 Addition Information PDP-10
Bit		 Tops-10 DAP Symbol Tops-20
DAP Symbol		 Tops-20
DAP Message
0 Stream Identification field present Means doing multiple streams on the same link 1B35 DF$SID HD$SID SID
1 Length field present Denotes the length  of  the OPERAND  field  (number  of 8-bit bytes) 1B34 DF$HLN HD$LEN LEN
2 If bit 1  (length field  present) is set, field  LEN256 is present and the length field is in effect 2 bytes long. Allows 64K message 1B33 DF$HL2 HD$LN2 LEN256
3 The BITCNT field is present Number of unused bits in final message.  Useful for variable byte size files. 1B32 DF$BCT HD$BCT BITCNT
4 Reserved (0) Means don't use this bit. 1B31 DF$XX1 HD$RSV *RESV*
5 SYSPEC field present This optional field is the system specific field which means that it can only be used for file access between two homogeneous systems. 1B30 DF$SHX HD$SHX SYSPEC
6 If set, this is a segmented message and this is not the last segment of the message.  The next message will contain the next segment of the full message. Means more data is coming for this segment. 1B29 DF$MOR HD$SEG SEG

Is this better?  What I'm saying is:

  1. I'm seeing DAP bit 4 getting set and I thought it wasn't supposed to be set, ever.
  2. I'm also seeing bit 9 get set, which isn't defined.
Do these reworded questions make sense now?

I'll see about getting a tcpdump or wireshark or something.

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@gmail.com> 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: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?  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 1B29 and not 1B28.  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@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se


_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se