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
