10 Dec
2019
10 Dec
'19
11:47 a.m.
Johnny Billquist <bqt at softjar.se> wrote:
Just checked.
On ATLE::
.copy kaka.txt=nul:
On TOPSY::
.r nft
*rename atle::[10,335]allan.txt=atle::[10,335]kaka.txt/u
For remote atle::[10,335]kaka.txt
User-id: 10,335
Account:
Password:
[10,335]allan.txt <= ATLE::DSKA:[10,335]KAKA.TXT
Total of 1 file
*
On ATLE:: again:
.dir kaka
%WLDNSF No such files as kaka
.dir allan
ALLAN TXT 0 <055> 10-Dec-19 DSKA: [10,335]
Log on ATLE:: contains:
11:38:25 FAL-Stream 0 -- Begin --
Servicing ANF-10 node ATLE for userid 10,335
11:38:25 FAL-Stream 0 -- End --
Servicing ANF-10 node ATLE for userid 10,335
So it seems to work under TOPS-10.
3. The
implementing DAP module (DAPLIB) appears even older, apparently
dating to V6.0, 1981 time-frame (which seems incorrect).?? It
supports DAP 5.6, for which I have the specifications.
* It does /not/ support $RENAME (ACCFUNC 3), which I found
remarkable.?? Is $RENAME supported on all other platforms?
It's certainly supported under RSX, and without doubt also under VMS. Johnny
--Johnny (the other one)
11 Dec
11 Dec
12:36 a.m.
Interesting.
Do you have source for the DAP/NFT/FAL on Tops-10 or know where I might
get what you have?
May I ask you what it does against a VMS system?? Unless it is reporting
DAP 7, my guess is that it won't work.
On 12/10/19 10:47 AM, Johnny Eriksson wrote:
Johnny Billquist <bqt at softjar.se> wrote:
Just checked.
On ATLE::
.copy kaka.txt=nul:
On TOPSY::
.r nft
*rename atle::[10,335]allan.txt=atle::[10,335]kaka.txt/u
For remote atle::[10,335]kaka.txt
User-id: 10,335
Account:
Password:
[10,335]allan.txt <= ATLE::DSKA:[10,335]KAKA.TXT
Total of 1 file
*
On ATLE:: again:
.dir kaka
%WLDNSF No such files as kaka
.dir allan
ALLAN TXT 0 <055> 10-Dec-19 DSKA: [10,335]
Log on ATLE:: contains:
11:38:25 FAL-Stream 0 -- Begin --
Servicing ANF-10 node ATLE for userid 10,335
11:38:25 FAL-Stream 0 -- End --
Servicing ANF-10 node ATLE for userid 10,335
So it seems to work under TOPS-10.
3. The
implementing DAP module (DAPLIB) appears even older, apparently
dating to V6.0, 1981 time-frame (which seems incorrect).?? It
supports DAP 5.6, for which I have the specifications.
* It does /not/ support $RENAME (ACCFUNC 3), which I found
remarkable.?? Is $RENAME supported on all other platforms?
It's
certainly supported under RSX, and without doubt also under VMS. Johnny
--Johnny (the other one) 
2:02 a.m.
On Dec 10, 2019, at 6:36 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
Interesting.
Do you have source for the DAP/NFT/FAL on Tops-10 or know where I might get what you
have?
May I ask you what it does against a VMS system? Unless it is reporting DAP 7, my guess
is that it won't work.
Why would you say that? The DECnet rule is backward compatibility, that's why the
version numbers are exchanged.
Actually, DAP takes this very seriously indeed, which is why it sends very long bitmaps
describing in detail all the protocol features supported.
It may well be that a V7 DAP implementation won't talk to V4 (Phase II). But I'd
be very surprised to see it fail talking to a V5.6 protocol peer -- I'm pretty sure
RSTS uses that version and we would certainly have complained if other Phase IV
implementations had trouble with that.
More in general, across the board the rule always was "One version back
compatible". So Phase IV can talk to Phase III (but not to Phase II -- except for
PyDecnet. :-) )
paul
4:03 a.m.
I would say it because of the code snippet at the bottom of G.'s,
letter, viz:
FAL$RENAME:: ; Entry point BBS #DAP$V_GEQ_V70,(R9),10$ ; *Exit if
partner does not support* BRW FAL$UNS_ACCFUNC ; *DAP V7.0*
The first instruction is a branch-on-bit-set and it looks like it is
testing a bit and branching if it is set. It would appear that bit is
associated with V7 DAP, based both on the symbolic value and comment. If
that branch isn't taken, then an unconditional branch is taken to what
appears to be an unsupported function return. However, I am in no way a
VAX assembly hacker. We looked it briefly when our chemistry department
got their first VAX and decided to stay with high level languages. While
the VAX had some fun stuff, the PDP-10's instruction set was considered
far easier; definitely the paging subsystem. However, I suspect that was
more because we had decades of experience with it. The VAX multiple byte
architecture had some remarkable similarities to a number of 360, 3033
and 4341's that we had, which weren't as much fun to program in
assembler. At any rate, that's why I said, "my guess".
On 12/10/19 8:02 PM, Paul Koning wrote:
On Dec 10, 2019, at 6:36 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
Interesting.
Do you have source for the DAP/NFT/FAL on Tops-10 or know where I might get what you
have?
May I ask you what it does against a VMS system? Unless it is reporting DAP 7, my guess
is that it won't work.
Why would you say that? The DECnet rule is backward
compatibility, that's why the version numbers are exchanged.
Actually, DAP takes this very seriously indeed, which is why it sends very long bitmaps
describing in detail all the protocol features supported.
It may well be that a V7 DAP implementation won't talk to V4 (Phase II). But I'd
be very surprised to see it fail talking to a V5.6 protocol peer -- I'm pretty sure
RSTS uses that version and we would certainly have complained if other Phase IV
implementations had trouble with that.
More in general, across the board the rule always was "One version back
compatible". So Phase IV can talk to Phase III (but not to Phase II -- except for
PyDecnet. :-) )
paul
8:47 a.m.
On Tue, 10 Dec 2019 22:03:35 -0500, Thomas DeBellis wrote:
The first instruction is a branch-on-bit-set and it
looks like it is
testing a bit and branching if it is set. It would appear that bit is
associated with V7 DAP, based both on the symbolic value and comment.
Correct. I'm far from being proficient at VAX assembly, but...
| 596 CHECK_PROTOCOL_VERSION: ; Set appropriate DAP$Q_DCODE_FLG bits
| 597 MOVZBL DAP$B_VERNUM(R9),R0 ; Combine version number and ECO
| 598 ASHL #8,R0,R0 ; number fields into one 16-bit
| 599 ADDB2 DAP$B_ECONUM(R9),R0 ; value for easy comparison
| 600
| 601 ;
| 602 ; Set status flag if partner implemented to DAP spec since V4.1.
| 603 ;
| 604
| 605 CMPW R0,#^X0401 ; Did partner implement since DAP V4.1?
| 606 BLSSU 10$ ; Branch if not
| 607 $SETBIT #DAP$V_GEQ_V41,(R9) ; Set flag
|
| [Same for V4.2, V5.2, V5.4, V5.6, and V6.0]
|
| 650 ; Set status flag if partner implemented to DAP spec since V7.0.
| 651 ;
| 652
| 653 CMPW R0,#^X0700 ; Did partner implement since DAP V7.0?
| 654 BLSSU 10$ ; Branch if not
| 655 $SETBIT #DAP$V_GEQ_V70,(R9) ; Set flag
| 656
|
| [Same for V7.1 and V7.2 too]
If that branch isn't taken, then an unconditional
branch is taken to what
appears to be an unsupported function return.
It seems so:
| 2462 ;++
| 2463 ; The ACCFUNC field value is unsupported for state table context.
| 2464 ;--
| 2465
| 2466 FAL$UNS_ACCFUNC:: ; Entry point
| 2467 MOVL #DAP$_ACCFUNC,R0 ; Get field ID code
| 2468 BRW ERR_UNSUPPORT ; Return error in Status message
| ....
| 3165 ;++
| 3166 ; Return DAP unsupported error.
| 3167 ; R0 contains DAP field ID code on input.
| 3168 ;--
| 3169
| 3170 ERR_UNSUPPORT: ; Entry point
| 3171 MOVZBL DAP$B_TYPE(R9),R1 ; Get DAP message type
| 3172 MOVL #DAP$_UNSUPPORT,R2 ; Get DAP MACCODE value
| 3173 BRB EXIT_STS_FAIL ; Send Status message
| ....
| 3183 ;++
| 3184 ; Build and send (failure) Status message to partner.
| 3185 ; Declare this last message of a response sequence and exit state with failure.
| 3186 ; R0 contains RMS completion code on input.
| 3187 ;--
| 3188
| 3189 EXIT_STS_FAIL: ; Entry point
| 3190 BISL2 #FAL$M_LAST_MSG,(R8) ; Declare this last message to block
| 3191 BSBW FAL$ENCODE_STS ; Build Status message
| 3192 BSBW FAL$TRANSMIT ; Send Status message to partner
G.
8:47 a.m.
On Tue, 10 Dec 2019 18:36:18 -0500, Thomas DeBellis wrote:
Interesting.
Do you have source for the DAP/NFT/FAL on Tops-10 or know where I might
get what you have?
I think that they might be these:
TOPS-10
-------
Last updates
http://pdp-10.trailing-edge.com/BB-JR93L-BB_1990/01/10,7/nft/nft.mac.html
http://pdp-10.trailing-edge.com/BB-JR93L-BB_1990/01/10,7/nft/nip.mac.html
Everything else is in the [10,7,NFT] directory here
http://pdp-10.trailing-edge.com/cuspbinsrc_2of2_bb-fp63b-sb/index.html
TOPS-20
-------
Last updates (which most probably you already have)
http://pdp-10.trailing-edge.com/CFS_TSU04_19910205_1of1/02/update/decsrc/da…
http://pdp-10.trailing-edge.com/CFS_TSU04_19910205_1of1/02/update/decsrc/da…
http://pdp-10.trailing-edge.com/CFS_TSU04_19910205_1of1/02/update/decsrc/dn…
http://pdp-10.trailing-edge.com/CFS_TSU04_19910205_1of1/02/update/decsrc/fa…
http://pdp-10.trailing-edge.com/CFS_TSU04_19910205_1of1/02/update/decsrc/nf…
G.
1839
days inactive
1840
days old
5 comments
4 participants
participants (4)
-
bygg＠cafax.se -
gerry77＠mail.com -
paulkoning＠comcast.net -
tommytimesharing＠gmail.com