"David R. Lennon" <dave at thelennons.net> writes:
Hi,
That macro version that Brian posted doesn't seem to be working
(no output) under OpenVMS 8.4 IA64 but this other version he posted
does:
https://mail.encompasserve.org/anon/htnotes/note?f1=DEC_NETWORKING&f2=1247.…
Hmm... I'm busy at the moment addressing pool (as in swimming, not memory)
issues. Opened the damned thing on Memorial day only to have the filter's
pump motor seize up. Just purchased a new one and I'm installing it, but I
need to run off to the hardware store. I checked email before heading out.
I'll take a look at the two examples later. It's been more than 2 decades
since I authored those programs and I haven't run Phase IV here in a decade
or more.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
"Bob Armstrong" <bob at jfcl.com> writes:
Source code?
You mean the VMS fiche ? Sorry - at one time I had access to a set, but
no more...
Well, these days, I read it from CD/DVD. ;)
1 259 %SBTTL 'NML$PROCESS_NICE Main command processing routine'
1 260
1 261 GLOBAL ROUTINE NML$PROCESS_NICE (msg_desc, resp_rtn): NOVALUE =
1 262
1 263 !++
1 264 ! This routine is the main command processing routine. NICE messages
1 265 ! are parsed to determine the requested function and then the proper
1 266 ! routine is called to perform the function.
1 267 !
1 268 ! Inputs:
1 269 !
1 270 ! msg_desc = Address of descriptor of NICE message
1 271 ! resp_rtn = Address of action routine to call with NICE response
1 272 ! The action routine is called with the following arguments:
1 273 ! 1) Address of descriptor of NICE response
1 274 !
1 275 ! Outputs:
1 276 !
1 277 ! None - control is returned after the last response has been passed
1 278 ! to the action routine.
1 279 !--
If you Google NML$PROCESS_NICE
Did that last night :-) There's not a lot, but I did find Nick deSmith's
netname.c example, and one other little code fragment, which was helpful.
The "Callback routine" is handed a descriptor.
I saw that. I was really hoping that the callback routine received an
extra generic parameter (like a Windows lParam or a VMS AST parameter) so
that the caller of NML$PROCESS_NICE could pass arbitrary additional
arguments to the callback. It doesn't look like that happens, though, so if
the callback wants to store or save any of the data that it gets, then it
has to do it globally.
It's far from perfect, I agree.
library module "$NMADEF" in the system called LIB.
Got that. Actually on OVMS 7.3 I don't have SYS$LIB_C.TLB or nmadef.h -
from some of the web comments I found, it sounds like those might exist only
on Alpha. No matter, though - $NMADEF is in MACRO32 is in LIB and it's
simple to extract $NMADEF to a MAR file. A little bit of emacs magic turned
it into a .h.
Extract it and use SDL!
The real problem is that there are no comments in $NMADEF, and my NICE
spec (AA-X437A-TK) only gives numeric values for everything. It's kind of
"take your best guess" as to which named constant actually corresponds to
the item you want.
Avoid the nameless constant values; include NMADEF from the library and use
its constant definitions.
Agreed!
Call NML$INITIALIZE; no parameters.
Call NML$PROCESS_NICE; NML request by descriptor, callback routine
Call NML$TERMINATE; no parameters.
The only serious piece I'm missing at this point is, what do you do if you
want to talk to NML on another node besides your own (e.g. "TELL yoyo SHOW
EXEC CHAR") ? There doesn't seem to be any NICE function that can be
embedded in the data stream to do this, and that wouldn't really make sense
anyway. That'd be like asking the local NML to talk to the remote one on
your behalf, and I don't think that's the way it works.
It seems like there should be some parameter to either NML$INITIALIZE or
NML$PROCESS_NICE that gives the node and access control information, but I
don't find any reference to that.
Thanks again for all the help, Brian.
Read the NML spec. You can do all you want via NICE. You simply need to
get the information about the remote node as known by your node and then,
compose the NICE message with the DECnet address in the NICE message. The
rest of the code all looks the same.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Hi,
That macro version that Brian posted doesn't seem to be working (no output) under OpenVMS 8.4 IA64 but this other version he posted does:
https://mail.encompasserve.org/anon/htnotes/note?f1=DEC_NETWORKING&f2=1247.…
The code he posted does have this comment:
; Read function options (RTFM. Sec 6.8 of DNA NML Network Mgt Spec #AA-X437A-TK)
which is a manual officially titled "DECnet Digital Network Architecture Phase IV Network Management Functional Specification", AA-X437A-TK and a scan is available online at:
http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/pdf/AA-X43…
Regards,
Dave
Quoting "Brian Schenkenberger, VAXman-" <system at tmesis.com>:
"Bob Armstrong" <bob at jfcl.com> writes:
Hey, thanks, Brian, for the example! Where are these NML$ library
routines documented? That's what I was looking for...
Source code? It's been so long since I wrote that example that I really do
not recall where *that* info was found. I typically document my code with
a RTFM reference. Of course, the only thin in that didty I posted was the
DNA NML Network Management Specification. There are only 3 entry points in
NMLSHR.EXE which you can see with an ANALYZE/IMAGE command.
Call NML$INITIALIZE; no parameters.
Call NML$PROCESS_NICE; NML request by descriptor, callback routine
Call NML$TERMINATE; no parameters.
The "Callback routine" is handed a descriptor. The first byte of the data
in the descriptor is a status. The status values, along with all of the
rest of the NMA constants, can be found in the library module "$NMADEF" in
the system called LIB. SYS$LIBRARY:LIB.MLB for macro; LIB.REQ for Bliss;
SYS$LIB_C.TLB for C.
If you Google NML$PROCESS_NICE, you will find some other tidbits of info.
One that was found when I did this is by friend Nick De Smith. It can be
found in the DECUS Library Compendium (DECUSlib.COM) which I too maintain.
NDS's example is written in C. I'd suggest NOT following NDS's example
too closely. Avoid the nameless constant values; include NMADEF from the
library and use its constant definitions.
Also, these calls will only work if you have DECnet phase IV installed on
your system. DECnet Phase V interface is a whole 'nother ball o' wax.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Source code?
You mean the VMS fiche ? Sorry - at one time I had access to a set, but
no more...
If you Google NML$PROCESS_NICE
Did that last night :-) There's not a lot, but I did find Nick deSmith's
netname.c example, and one other little code fragment, which was helpful.
The "Callback routine" is handed a descriptor.
I saw that. I was really hoping that the callback routine received an
extra generic parameter (like a Windows lParam or a VMS AST parameter) so
that the caller of NML$PROCESS_NICE could pass arbitrary additional
arguments to the callback. It doesn't look like that happens, though, so if
the callback wants to store or save any of the data that it gets, then it
has to do it globally.
library module "$NMADEF" in the system called LIB.
Got that. Actually on OVMS 7.3 I don't have SYS$LIB_C.TLB or nmadef.h -
from some of the web comments I found, it sounds like those might exist only
on Alpha. No matter, though - $NMADEF is in MACRO32 is in LIB and it's
simple to extract $NMADEF to a MAR file. A little bit of emacs magic turned
it into a .h.
The real problem is that there are no comments in $NMADEF, and my NICE
spec (AA-X437A-TK) only gives numeric values for everything. It's kind of
"take your best guess" as to which named constant actually corresponds to
the item you want.
Avoid the nameless constant values; include NMADEF from the library and use
its constant definitions.
Agreed!
Call NML$INITIALIZE; no parameters.
Call NML$PROCESS_NICE; NML request by descriptor, callback routine
Call NML$TERMINATE; no parameters.
The only serious piece I'm missing at this point is, what do you do if you
want to talk to NML on another node besides your own (e.g. "TELL yoyo SHOW
EXEC CHAR") ? There doesn't seem to be any NICE function that can be
embedded in the data stream to do this, and that wouldn't really make sense
anyway. That'd be like asking the local NML to talk to the remote one on
your behalf, and I don't think that's the way it works.
It seems like there should be some parameter to either NML$INITIALIZE or
NML$PROCESS_NICE that gives the node and access control information, but I
don't find any reference to that.
Thanks again for all the help, Brian.
Bob
"Bob Armstrong" <bob at jfcl.com> writes:
Hey, thanks, Brian, for the example! Where are these NML$ library
routines documented? That's what I was looking for...
Source code? It's been so long since I wrote that example that I really do
not recall where *that* info was found. I typically document my code with
a RTFM reference. Of course, the only thin in that didty I posted was the
DNA NML Network Management Specification. There are only 3 entry points in
NMLSHR.EXE which you can see with an ANALYZE/IMAGE command.
Call NML$INITIALIZE; no parameters.
Call NML$PROCESS_NICE; NML request by descriptor, callback routine
Call NML$TERMINATE; no parameters.
The "Callback routine" is handed a descriptor. The first byte of the data
in the descriptor is a status. The status values, along with all of the
rest of the NMA constants, can be found in the library module "$NMADEF" in
the system called LIB. SYS$LIBRARY:LIB.MLB for macro; LIB.REQ for Bliss;
SYS$LIB_C.TLB for C.
If you Google NML$PROCESS_NICE, you will find some other tidbits of info.
One that was found when I did this is by friend Nick De Smith. It can be
found in the DECUS Library Compendium (DECUSlib.COM) which I too maintain.
NDS's example is written in C. I'd suggest NOT following NDS's example
too closely. Avoid the nameless constant values; include NMADEF from the
library and use its constant definitions.
Also, these calls will only work if you have DECnet phase IV installed on
your system. DECnet Phase V interface is a whole 'nother ball o' wax.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
On 2014-05-28 20:19, Cory Smelosky wrote:
On Wed, 28 May 2014, Johnny Billquist wrote:
I would guess on a bad XXDP image, since XXDP requires almost nothing
working. If RSRS/E and RSX works then I can't imagine XXDP not working.
As soon as I figure out how the hell to write a disk image from RSTS/E
I'll try a new image. ;)
Can't MOUNT FOREIGN so I need to read more manuals it appears.
If you have RSX-11M-PLUS V4.6 up and running, it already have a tool for doing this. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2014-05-27 23:08, Hans Vlems wrote:
Area 44 is missing from the list.
Johnny, did you turn off the bridge link to my LAN?
Nope.
Is your address still 87.209.50.192 ?
Johnny
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Bob Armstrong
Verzonden: dinsdag 27 mei 2014 22:50
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] "Dropped by adjacent node" ....
I appreciate the suggestions, but I'm not really interested in trying to
re-architect HECnet. That's a losing battle - I just want my node to work
:-)
I tried sending the USR1 signal to the bridge program and got this -
0: legato 0.0.0.0:0000 (Rx: 827 Tx:11017 (Drop rx: 6)) Active: 1
Throttle: 278(114)
1: psilo 130.238.19:4711 (Rx:11044 Tx: 821 (Drop rx: 27)) Active: 1
Throttle: 115(332)
Hash of known destinations:
aa0004000d04 -> 1 (1.13)
aa0004000f04 -> 1 (1.15)
aa0004001404 -> 1 (1.20)
aa0004001504 -> 1 (1.21)
aa0004005e05 -> 1 (1.350)
aa000400c205 -> 1 (1.450)
aa0004000108 -> 0 (2.1)
aa000400f810 -> 1 (4.248)
aa000400ff17 -> 1 (5.1023)
aa0004009021 -> 1 (8.400)
aa0004009121 -> 1 (8.401)
aa000400bc21 -> 1 (8.444)
aa000400f421 -> 1 (8.500)
aa000400022c -> 1 (11.2)
aa000400032c -> 1 (11.3)
aa000400642c -> 1 (11.100)
aa0004000138 -> 1 (14.1)
aa000400284c -> 1 (19.40)
aa000400294c -> 1 (19.41)
aa0004000470 -> 1 (28.4)
aa0004002970 -> 1 (28.41)
aa000400feab -> 1 (42.1022)
aa0004002fbc -> 1 (47.47)
aa0004004dbd -> 1 (47.333)
aa0004002bbe -> 1 (47.555)
aa0004002cbe -> 1 (47.556)
aa0004002fbe -> 1 (47.559)
aa000400bcbe -> 1 (47.700)
aa000400bdbe -> 1 (47.701)
aa000400d7be -> 1 (47.727)
aa0004000bec -> 1 (59.11)
aa00040005f8 -> 1 (62.5)
aa0004007dfa -> 1 (62.637)
Note that I restarted it about 30 minutes ago, so this data is just for
that period of time. My first observation is that's a lot of routing nodes,
but that's probably neither here nor there.
Also I'm struck by the asymmetry in the number of packets sent vs
received. I guess that makes sense, since I'm transmitting routing and
hello messages for only one node (LEGATO) and receiving them from beaucoup
nodes.
And I'm not sure that the throttling in the bridge is about...
Bob
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2014-05-28 15:56, Paul_Koning at Dell.com wrote:
On May 28, 2014, at 9:40 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-28 15:33, Paul_Koning at Dell.com wrote:
...
DDCMP is a data link layer that deals with packet loss. It also deals with reordering, within reason, by treating it as packet loss, just as NSP did until Phase V. It should be ok with limited duplication as well though duplication is not one of the supposed characteristics of UDP.
Duplication is definitely a possible event with UDP. It happens from time to time. It's essentially because duplication is possible with IP. UDP is just IP with ports and a checksum (if you are lucky). And IP makes no promises at all. Packets might not arrive, might arrive out of order, become duplicated, delayed, or even corrupted.
Note that I meant the DDCMP protocol, not the DDCMP point to point service. In other words, the UDP packets would carry DDCMP frames, with DDCMP header (including sequence number and all that). I think SIMH has that right now, in V4.0 DMC emulation.
Ok. So if I understand correctly, DDCMP is guaranteeing the delivery of data between the two points. Data will arrive in order and without any loss or other confusion, as seen by the layers above DDCMP?
Yes, just as with TCP. The usual disclaimers apply. For example, dups or reorders are detected only up to the wrap point of the sequence number space. Corruption is caught only up to the capabilities of the CRC being used.
Also, guaranteed delivery is a commonly used term. A more accurate term would be guaranteed delivery or notification of failure . Connection oriented services like DDCMP and TCP and TP4 and NSP will deliver the data stream intact to the other end, OR they will tell you that they could not do so.
Seems like UDP could work then, but maybe TCP would be better?
Not clear. If things get reordered or delayed to the point that the DDCMP sequence number space is no longer sufficient, then TCP would help. It makes things somewhat more complicated (as Rob Jarratt pointed out) because TCP introduces the asymmetry of who connects while DDCMP does not have than and neither does UDP.
Right. However, I also wonder if the retry and recover mechanisms in TCP might be faster and more efficient than what DDCMP do. But like I said, I have not looked, so I'm just guessing.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
"Bob Armstrong" <bob at jfcl.com> writes:
I want to write a little C program that talks to NML without, say,
spawning NCP to execute commands. I found a specification for Phase IV
NICE, which is doable but a bit complicated. Does anyone know if there's an
NML/NICE interface library of some kind?
================
File NML.MAR is:
================
;++
; Copyright 1992, by Brian Schenkenberger and TMESIS. ALL RIGHTS RESERVED.
;
; This software is provided "AS IS" and is supplied for informational purpose
; only. No warranty is expressed or implied and no liability can be accepted
; for any actions or circumstances incurred from the use of this software or
; from the information contained herein. The author makes no claim as to the
; suitablility or fitness of the software or information contain herein for a
; particular purpose.
;
; Permission is hereby granted *ONLY* for the "not-for-profit" redistribution
; of this software provided that ALL SOURCE and/or OBJECT CODE remains intact
; and ALL COPYRIGHT NOTICES remain intact from its original distribution.
;
;(!) NO TITLE TO AND/OR OWNERSHIP OF THIS SOFTWARE IS HEREBY TRANSFERRED. (!)
;--
; This program uses the DECnet Network Information Command Exchange Protocol
; or NICE protocol (which it is anything but nice if you should have a chance
; to read the functional spec.)
;
; This is a quick and dirty ditty to print out the nodes which your node can
; see as active or reachable nodes.
;
; NICE is comprised of a set of functions (LOOP, LOAD, READ, etc.) to which
; a structure of option functions is attached. A callable interface, the
; NML$xxx calls, facilitate the use of the NICE codes. FYI, you can also
; open a channel to another nodes NML object and request information from it
; using NICE protocols.
;
; I built this example with the NML$xxx calls because it facilitates the
; disassembly of the information returned by the requested NICE command.
;
; I'm a MacroMan so naturally, this example is in Macro. If you're one of
; the followers of fanciful programming fad, you can probaby translate this
; into (eek) 'C' or any other HOL.
;--
; To build:
; $ MACRO NML
; $ LINK NML,SYS$INPUT/OPT
; SYS$SHARE:NMLSHR.EXE/SHARE
; ^Z
;--
.TITLE NML
.LIBRARY "SYS$LIBRARY:STARLET.MLB" ; look here for...
$DSCDEF ; defines, symbolocally, OpenVMS descriptor codes
$LIB$ROUTINESDEF; defines macros for the OpenVMS LIB$ RTL routines
.LIBRARY "SYS$LIBRARY:LIB.MLB" ; look here for...
$NMADEF ; defines, symbolically, NICE/NML function codes
.PSECT $$DATA,WRT,NOEXE,5
;++
; Read function options (RTFM. Sec 6.8 of DNA NML Network Mgt Spec #AA-X437A-TK)
;--
OPTION = <NMA$C_ENT_NOD at NMA$V_OPT_ENT>!- ; Entity type = node
<NMA$C_OPINF_SUM at NMA$V_OPT_INF>!- ; inform type = summary
<0 at NMA$V_OPT_PER> ; Read volatile database
; <1 at NMA$V_OPT_PER> ; Read permanent database
REQST: .ASCID <NMA$C_FNC_REA><OPTION><NMA$C_ENT_KNO>
.ALIGN QUAD
NODE: .ADDRESS DESC
DESC: .QUAD 0
OUTPUT: .LONG <DSC$K_CLASS_D@<DSC$B_CLASS at 3>>!-
<DSC$K_DTYPE_T@<DSC$B_DTYPE at 3>>,0
FORMAT: .ASCID /Node: !6AS DECnet address: !UL.!UL/
.PSECT $$CODE,NOWRT,EXE
.ENTRY START_NML,0
CALLS #0,G^NML$INITIALIZE ; init the NML interface
PUSHAB CALLBACK_ROUTINE ; addr of rtn to output data
PUSHAB REQST ; desc of NICE request
CALLS #2,G^NML$PROCESS_NICE ; call interface, process request
CALLS #0,G^NML$TERMINATE
$EXIT_S
RET
;++
; The callback routine is called by the NML$PROCESS_NICE function with
; the address of a descriptor and will called repeatedly until all the
; information requested is exhausted. First byte of the data described
; by the descriptor is a status byte. The rest is data, passed in a
; format with is unique to each NICE functional operation and is detailed
; in the functional spec.
;--
$OFFDEF CALLBACK_ROUTINE,DESCRIPTOR
.ENTRY CALLBACK_ROUTINE,0
MOVQ @CALLBACK_ROUTINE$_DESCRIPTOR(AP),R0
CMPB (R1),#NMA$_SUCCESS
BEQL 10$
RET
;++
; Here, as per the NML spec, the information is process... The beginning of
; the response string is formatted as such:
;
;
; |<-- ascic node name
; | |<-- node number
; | | |<-- status
; +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
; | | | | F| E| D| C| B| A| #| | | | | | |
; +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
;--
10$: TSTL (R1)+ ; move pointer forward 4 bytes
MOVZWL (R1)+,R0 ; get the node number
EXTZV #0,#7,(R1)+,DESC ; get the node name length
MOVAB (R1),DESC+4 ; get the node name address
EXTZV #NMA$V_ADDR,#NMA$S_ADDR,R0,R1 ; get the node number
EXTZV #NMA$V_AREA,#NMA$S_AREA,R0,R0 ; get the area number
$LIB_SYS_FAO_S character_string = FORMAT,-
resultant_string = OUTPUT,-
directive_argument1 = NODE,-
directive_argument2 = R0,-
directive_argument3 = R1
$LIB_PUT_OUTPUT_S message_string = OUTPUT
RET
.END START_NML
================
File NML.OPT is:
================
SYS$SHARE:NMLSHR.EXE/SHAREABLE
$ MACRO NML.MAR
$ LINK NML.MAR,NML.OPT/OPTION
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
I want to write a little C program that talks to NML without, say, spawning NCP to execute commands. I found a specification for Phase IV NICE, which is doable but a bit complicated. Does anyone know if there s an NML/NICE interface library of some kind?
Thanks,
Bob
On May 28, 2014, at 2:54 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Wed, 28 May 2014, Paul_Koning at Dell.com wrote:
On RSTS, to access a disk without using the RSTS file system ( non file structured mode ) you don t mount it, you just refer to the device name. For example, in BASIC you d use the device name in an OPEN statement, without a file name part: open db0: as file 1%
$ copy moira::xxdp25.dsk du2:
Node: MOIRA
User: csmelosky
Password:
System Password:
Event type 33.0, Remote file access
Occurred 14-May-27 14:52:59.2 on node 9.4 (MANDY)
Access: Remote
Function: OPEN/Read
Remote node = 9.1 (MOIRA)
Remote process = 17 0 0
Local process = 0 1 2 NFT002
User = csmelosky
File accessed = 0 MOIRA$DKA100:[CSMELOSKY]XXDP25.DSK;1
?NFT -- Device name syntax error
I take it copy takes different syntax? ;)
No the problem is that you can t do non-file operations there. In RSTS, only some applications allow non-file operations; basically, they have to know how to issue open requests with no file name part supplied. A lot of applications supply default file name pieces if you don t supply your own; NFT/FAL (network copy) is one such, for that matter so is regular file copy.
You d have to copy the input file to a file on the target system, then do the non-file structured copy as a separate step. And the easiest way to do that second step is probably with a half dozen lines of BASIC code I can t think of an off the shelf program that will do the job.
paul
On Wed, 28 May 2014, Paul_Koning at Dell.com wrote:
On RSTS, to access a disk without using the RSTS file system ( non file structured mode ) you don t mount it, you just refer to the device name. For example, in BASIC you d use the device name in an OPEN statement, without a file name part: open db0: as file 1%
$ copy moira::xxdp25.dsk du2:
Node: MOIRA
User: csmelosky
Password:
System Password:
Event type 33.0, Remote file access
Occurred 14-May-27 14:52:59.2 on node 9.4 (MANDY)
Access: Remote
Function: OPEN/Read
Remote node = 9.1 (MOIRA)
Remote process = 17 0 0
Local process = 0 1 2 NFT002
User = csmelosky
File accessed = 0 MOIRA$DKA100:[CSMELOSKY]XXDP25.DSK;1
?NFT -- Device name syntax error
I take it copy takes different syntax? ;)
You need privs for this logged in as 1,x under V8 or older, WRTNFS privs on V9 or later (which typically are set on 1,x accounts).
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
On May 28, 2014, at 2:19 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Wed, 28 May 2014, Johnny Billquist wrote:
I would guess on a bad XXDP image, since XXDP requires almost nothing working. If RSRS/E and RSX works then I can't imagine XXDP not working.
As soon as I figure out how the hell to write a disk image from RSTS/E I'll try a new image. ;)
Can't MOUNT FOREIGN so I need to read more manuals it appears.
On RSTS, to access a disk without using the RSTS file system ( non file structured mode ) you don t mount it, you just refer to the device name. For example, in BASIC you d use the device name in an OPEN statement, without a file name part: open db0: as file 1%
You need privs for this logged in as 1,x under V8 or older, WRTNFS privs on V9 or later (which typically are set on 1,x accounts).
paul
On Wed, 28 May 2014, Johnny Billquist wrote:
I would guess on a bad XXDP image, since XXDP requires almost nothing working. If RSRS/E and RSX works then I can't imagine XXDP not working.
As soon as I figure out how the hell to write a disk image from RSTS/E I'll try a new image. ;)
Can't MOUNT FOREIGN so I need to read more manuals it appears.
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
Sorry about that, I did not pay attention, it had rebooted a image that does
everything except forward DECnet packets, so what I was using it for worked fine...
It's back up again. All configs still in place.
--P
With help and a pointer from Peter, we ve set up the DECnet over Multinet link between LEGATO and STUPI to use TCP instead of UDP. It seems to work fine whether it s better than the UDP version only time will tell.
It turns out that none of this is magic it s all pretty well documented by Process Software. Just type HELP MULTINET SET /DECNET and you ll see the /TCP qualifier.
There s also a /FILTER_OUT_OF_ORDER qualifier which forces the driver to drop out of order UDP packets. Of course, that doesn t apply to TCP, but it does remove that objection to the UDP implementation.
Bob
On May 28, 2014, at 9:40 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-28 15:33, Paul_Koning at Dell.com wrote:
...
DDCMP is a data link layer that deals with packet loss. It also deals with reordering, within reason, by treating it as packet loss, just as NSP did until Phase V. It should be ok with limited duplication as well though duplication is not one of the supposed characteristics of UDP.
Duplication is definitely a possible event with UDP. It happens from time to time. It's essentially because duplication is possible with IP. UDP is just IP with ports and a checksum (if you are lucky). And IP makes no promises at all. Packets might not arrive, might arrive out of order, become duplicated, delayed, or even corrupted.
Note that I meant the DDCMP protocol, not the DDCMP point to point service. In other words, the UDP packets would carry DDCMP frames, with DDCMP header (including sequence number and all that). I think SIMH has that right now, in V4.0 DMC emulation.
Ok. So if I understand correctly, DDCMP is guaranteeing the delivery of data between the two points. Data will arrive in order and without any loss or other confusion, as seen by the layers above DDCMP?
Yes, just as with TCP. The usual disclaimers apply. For example, dups or reorders are detected only up to the wrap point of the sequence number space. Corruption is caught only up to the capabilities of the CRC being used.
Also, guaranteed delivery is a commonly used term. A more accurate term would be guaranteed delivery or notification of failure . Connection oriented services like DDCMP and TCP and TP4 and NSP will deliver the data stream intact to the other end, OR they will tell you that they could not do so.
Seems like UDP could work then, but maybe TCP would be better?
Not clear. If things get reordered or delayed to the point that the DDCMP sequence number space is no longer sufficient, then TCP would help. It makes things somewhat more complicated (as Rob Jarratt pointed out) because TCP introduces the asymmetry of who connects while DDCMP does not have than and neither does UDP.
paul
On 2014-05-28 15:33, Paul_Koning at Dell.com wrote:
On May 27, 2014, at 8:53 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 22:09, Paul_Koning at Dell.com wrote:
On May 27, 2014, at 4:04 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 21:48, Bob Armstrong wrote:
The way to run DECnet over a flaky long distance network is to use point
to point mode with a data link layer that deals with packet loss.
Probably a good idea, but we don't have that option on HECnet.
Well, HECnet is not a static piece of equipment. Anything is possible...
My bridge emulates a simple ethernet segment. Good enough many times, but if we have a link like yours, that sometimes seems to drop packets, then maybe some other alternative should be considered.
Now, the question then becomes, what can we do in this case.
As far as I understand, links using Multinet are more broken, and still use UDP. The same would appear to possibly be the case for Cisco as well?
Do anyone run any links using TCP?
That would work. DDCMP over UDP would work.
Really? UDP can cause packets to arrive in the wrong order, duplicated, or sometimes dropped. I was certain you wrote above "a data link layer that deals with packet loss". Or was that not meant to be read as that the underlaying transport should deal with it?
DDCMP is a data link layer that deals with packet loss. It also deals with reordering, within reason, by treating it as packet loss, just as NSP did until Phase V. It should be ok with limited duplication as well though duplication is not one of the supposed characteristics of UDP.
Duplication is definitely a possible event with UDP. It happens from time to time. It's essentially because duplication is possible with IP. UDP is just IP with ports and a checksum (if you are lucky). And IP makes no promises at all. Packets might not arrive, might arrive out of order, become duplicated, delayed, or even corrupted.
Note that I meant the DDCMP protocol, not the DDCMP point to point service. In other words, the UDP packets would carry DDCMP frames, with DDCMP header (including sequence number and all that). I think SIMH has that right now, in V4.0 DMC emulation.
Ok. So if I understand correctly, DDCMP is guaranteeing the delivery of data between the two points. Data will arrive in order and without any loss or other confusion, as seen by the layers above DDCMP?
Seems like UDP could work then, but maybe TCP would be better?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On May 27, 2014, at 8:53 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 22:09, Paul_Koning at Dell.com wrote:
On May 27, 2014, at 4:04 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 21:48, Bob Armstrong wrote:
The way to run DECnet over a flaky long distance network is to use point
to point mode with a data link layer that deals with packet loss.
Probably a good idea, but we don't have that option on HECnet.
Well, HECnet is not a static piece of equipment. Anything is possible...
My bridge emulates a simple ethernet segment. Good enough many times, but if we have a link like yours, that sometimes seems to drop packets, then maybe some other alternative should be considered.
Now, the question then becomes, what can we do in this case.
As far as I understand, links using Multinet are more broken, and still use UDP. The same would appear to possibly be the case for Cisco as well?
Do anyone run any links using TCP?
That would work. DDCMP over UDP would work.
Really? UDP can cause packets to arrive in the wrong order, duplicated, or sometimes dropped. I was certain you wrote above "a data link layer that deals with packet loss". Or was that not meant to be read as that the underlaying transport should deal with it?
DDCMP is a data link layer that deals with packet loss. It also deals with reordering, within reason, by treating it as packet loss, just as NSP did until Phase V. It should be ok with limited duplication as well though duplication is not one of the supposed characteristics of UDP.
Note that I meant the DDCMP protocol, not the DDCMP point to point service. In other words, the UDP packets would carry DDCMP frames, with DDCMP header (including sequence number and all that). I think SIMH has that right now, in V4.0 DMC emulation.
paul
Higher up the thread there was mention of using DDCMP, and also of the fact that missing 3 hello messages will cause the adjacency to go down.
Well, the user mode router I have written implements DDCMP now, over TCP. It still has some strange issues that I need to resolve, and it is only passive (ie it won't initiate a connection to a peer). But, it is mostly there otherwise. You can work around the passiveness by using SIMH at the other end and using the emulated DMC11.
Additionally, while I implement the 3 hello limit for Ethernet circuits (BC3TMULT in the routing spec), that could be changed quite easily to be a higher limit, but you would need the router to be configured the same way at both ends of the link for that to work.
Regards
Rob
On 28 May 2014 07:47, Pontus Pihlgren <pontus at update.uu.se> wrote:
On Tue, May 27, 2014 at 11:13:05PM +0200, Peter Lothberg wrote:
>
> (I might even find a switch that does it right and send it to Update)
If you do, we'll try not to procrastinate setting it up for a year :-)
/P
On 2014-05-28 08:52, Cory Smelosky wrote:
Hello all,
So...I have an 11/23+ here that runs RSTS/E and RSX-11M+ however...it
fails to even BOOT XXDP. Which is...interesting to say the least.
The disk image I made booted fine in simh. When I boot it it just drops
me back to ODT with the last address...which was REALLY soon after boot.
Could it be the same RSTS/E disk image size issue I had before? Any
ideas? My bus is contiguous, this part of memory is good, and RSTS/E
and RSX-11M+ work fine.
I would guess on a bad XXDP image, since XXDP requires almost nothing working. If RSRS/E and RSX works then I can't imagine XXDP not working.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
Hello all,
So...I have an 11/23+ here that runs RSTS/E and RSX-11M+ however...it fails to even BOOT XXDP. Which is...interesting to say the least.
The disk image I made booted fine in simh. When I boot it it just drops me back to ODT with the last address...which was REALLY soon after boot.
Could it be the same RSTS/E disk image size issue I had before? Any ideas? My bus is contiguous, this part of memory is good, and RSTS/E and RSX-11M+ work fine.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Tue, May 27, 2014 at 11:13:05PM +0200, Peter Lothberg wrote:
(I might even find a switch that does it right and send it to Update)
If you do, we'll try not to procrastinate setting it up for a year :-)
/P
