linux-decnet-user — Discussion for users of DECnet on Linux

RE: [Linux-decnet-user] Restore performance

[Gustavo B. <gb...@na...>]

Well, backup/verify takes almost forever (I stopped the process because
I needed the computer to do some useful stuff).


-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
Patrick Caulfield
Sent: Friday, April 23, 2004 11:43 AM
To: lin...@li...
Subject: Re: [Linux-decnet-user] Restore performance


On Fri, Apr 23, 2004 at 11:03:59AM -0300, Gustavo Boado wrote:
> Weird...I tried a backup yesterday... 1.2 GB disk on the Alpha. Backup

> took about 30 minutes, restore about 15 hours. I will keep trying.

OUCH! that sounds like more than just a little filesystem overhead. I
can't imagine what might cause a 30x slowdown like that.

A few things you might like to try:

- run "fal -ae -r exported -vvvv" as root and see if anything odd shows
up.
- Check the fal process for disk or memory thrashing
- try backup/compare & backup/list to see if they are similarly
affected.
- do a tcpdump to see if the packets start getting delayed for any
reason.

I am going to be away for a week from tonight but if you have any
interesting results or ideas I'd like to see them

-- 

patrick


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For
a limited time only, get FREE Ground shipping on all orders of $35 or
more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Linux-decnet-user mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

Re: [Linux-decnet-user] Restore performance

[Patrick C. <pa...@ty...>]

On Fri, Apr 23, 2004 at 11:03:59AM -0300, Gustavo Boado wrote:
> Weird...I tried a backup yesterday... 1.2 GB disk on the Alpha. Backup
> took about 30 minutes, restore about 15 hours.
> I will keep trying.

OUCH! that sounds like more than just a little filesystem overhead. I can't
imagine what might cause a 30x slowdown like that.

A few things you might like to try:

- run "fal -ae -r exported -vvvv" as root and see if anything odd shows up.
- Check the fal process for disk or memory thrashing
- try backup/compare & backup/list to see if they are similarly affected.
- do a tcpdump to see if the packets start getting delayed for any reason.

I am going to be away for a week from tonight but if you have any
interesting results or ideas I'd like to see them

-- 

patrick

RE: [Linux-decnet-user] Restore performance

[Gustavo B. <gb...@na...>]

Weird...I tried a backup yesterday... 1.2 GB disk on the Alpha. Backup
took about 30 minutes, restore about 15 hours.
I will keep trying.


-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
Patrick Caulfield
Sent: Friday, April 23, 2004 6:22 AM
To: lin...@li...
Subject: Re: [Linux-decnet-user] Restore performance


hmm, although my timings aren't as diverse as yours they do look as if
it's VMS' write performance that's most of the hit.

to a Linux FAL: 

backup takes 10 minutes
backup/compare takes 10 minutes
restore (to a new disk) takes 18 minutes
restore (to subdir of original disk) takes 20 minutes

Then I tried it to a VMS server (Alpha pws433, VMS 7.3-1) backup took 9
minutes backup/compare took 9 minutes restore took 17 minutes

-- 

patrick
(whaddya mean "don't I have anything better to do?"!)


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For
a limited time only, get FREE Ground shipping on all orders of $35 or
more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
Linux-decnet-user mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

Re: [Linux-decnet-user] Restore performance

[Patrick C. <pa...@ty...>]

hmm, although my timings aren't as diverse as yours they do look as if it's VMS'
write performance that's most of the hit.

to a Linux FAL: 

backup takes 10 minutes
backup/compare takes 10 minutes
restore (to a new disk) takes 18 minutes
restore (to subdir of original disk) takes 20 minutes

Then I tried it to a VMS server (Alpha pws433, VMS 7.3-1)
backup took 9 minutes
backup/compare took 9 minutes
restore took 17 minutes

-- 

patrick
(whaddya mean "don't I have anything better to do?"!)

Re: [Linux-decnet-user] Restore performance

[David M. <da...@mi...>]

On 4/22/2004 11:05 AM +0100, Patrick Caulfield wrote:
>Well, I'm interested now (and the server is down at work...)
>
>I just tried this with a 260MB disk image on a MicroVAX 3100-95
>
>   backup/image dka100: 1.10"patrick password"::test.bck/save
>
>took 7 minutes
>
>   backup 1.10"patrick password"::test.bck/save/list=nl:
>
>took 6 minutes (nice and symmetrical)
>
>   backup 1.10"patrick password"::test.bck/save dka100:[pjctest...]
>
>took 20 minutes !
>
>The really odd thing is that the fal logs for the last two are almost 
>identical.
>This is on a home 10Mb/s network (at least the VAX only has 10Meg ethernet
>in it) so it's guaranteed quiet and so is the server (dual PIII/750)
>
>So, more detailed invesetigation needed..any VMS experts have ideas ??
>
>patrick


Gack, haven't done this in eons... so I'm rusty.  Some ideas FWIW:

Do you get a DAP block mode transfer in each direction?
(presumbly the push does, but what about the pull on the restore)

Do you have inter-packet timings on the NSP credit flow?
(which node is slowing things down?)
Either the VAX is blocking the dataflow (cuz it's slow processing or needs 
more buffering), or the Linux FAL is slow to send the next block.

Hmm... I still have some hardcopies of my DAP protocol reference card.
(Softcopy is in a Xerox Star file)
I should scan it.

Dave.

Re: [Linux-decnet-user] Restore performance

[Patrick C. <pa...@ty...>]

Well, I'm interested now (and the server is down at work...)

I just tried this with a 260MB disk image on a MicroVAX 3100-95

  backup/image dka100: 1.10"patrick password"::test.bck/save
  
took 7 minutes

  backup 1.10"patrick password"::test.bck/save/list=nl:

took 6 minutes (nice and symmetrical)

  backup 1.10"patrick password"::test.bck/save dka100:[pjctest...]

took 20 minutes !

The really odd thing is that the fal logs for the last two are almost identical.
This is on a home 10Mb/s network (at least the VAX only has 10Meg ethernet
in it) so it's guaranteed quiet and so is the server (dual PIII/750)

So, more detailed invesetigation needed..any VMS experts have ideas ??

patrick

Re: [Linux-decnet-user] Restore performance

[Patrick C. <pa...@ty...>]

On Wed, Apr 21, 2004 at 11:55:05PM +0200, Rok Vidmar, NUK Ljubljana wrote:
> > I'll set up my test box and see if I can find out what's happening.
> 
>  Don't bother. It is natural to take image backup (much) less then
> normal backup.
> 

I would hope so :-)

However, you've got me interested now so I will have a look - but maybe not this
week as I'll be away for a bit from now.

patrick

RE: [Linux-decnet-user] Restore performance

[Rok V. N. L. <rok...@NU...>]

> I'll set up my test box and see if I can find out what's happening.

 Don't bother. It is natural to take image backup (much) less then
normal backup.

Regards,

Rok Vidmar                       Internet:  rok...@nu...
National and University Library  Phone:     +386 1 421 5461
Turjaska 1, SI-1000 Ljubljana    Fax:       +386 1 421 5464
Slovenia

Re: [Linux-decnet-user] Restore performance

[Patrick C. <pa...@ty...>]

On Wed, Apr 21, 2004 at 11:04:36AM -0300, Gustavo M. Boado wrote:
> Well, this was a QUICK response...
> Regarding the commands, to perform the backup I use:
> 
> BACKUP /IMAGE/IGNORE=LABEL DKA0: 21.42"OFFLINE password"::PP.BCK/SAVE
> 
> It takes about 20 minutes to backup a system disk with about 600 MB of data. The source is an AlphaStation 200/166 with OpenVMS 7.1 and 10 Mbps network card running through a switch.
> 21.42 is the DECNet address of the Linux node. The Linux computer runs a standard 2.4.25 kernel with dnprogs 2.26. It is an Athlon 2200XP with 256 MB RAM and very light load (none at the time of the backup).
> 
> To perform the restore I do:
> 
> BACKUP 21.42OFFLINE password"::PP.BCK/SAVE DKA0:[*...] /BY_OWNER
> 
> Then I do the usual writeboot stuff.
> The process works properly but it takes about 4 hours.
> The only FAL options I am using (in the dnetd.conf file) are -ae -r /offline
> /offline is the exported path.
> Standard file copy is fast (I didn't benchmark the system but it looks fine). I changed NSP_MAX_WINDOW to 1 in dn.h to improve the performance of the file copy (as it was suggested somewhere in the net) but the restore performance wasn't improved.

That FAL option looks fine. The thing to do is to run fal with -vvvv -ae and
have a look at the messages that are being sent. It's possible that BACKUP is
setting some optins that FAL doesn't recognise as allowing it to do streaming
IO, but I'm guessing here. 

I'll set up my test box and see if I can find out what's happening.

patrick

RE: [Linux-decnet-user] Restore performance

[Gustavo M. B. <gb...@na...>]

Well, this was a QUICK response...
Regarding the commands, to perform the backup I use:

BACKUP /IMAGE/IGNORE=3DLABEL DKA0: 21.42"OFFLINE password"::PP.BCK/SAVE

It takes about 20 minutes to backup a system disk with about 600 MB of =
data. The source is an AlphaStation 200/166 with OpenVMS 7.1 and 10 Mbps =
network card running through a switch.
21.42 is the DECNet address of the Linux node. The Linux computer runs a =
standard 2.4.25 kernel with dnprogs 2.26. It is an Athlon 2200XP with =
256 MB RAM and very light load (none at the time of the backup).

To perform the restore I do:

BACKUP 21.42OFFLINE password"::PP.BCK/SAVE DKA0:[*...] /BY_OWNER

Then I do the usual writeboot stuff.
The process works properly but it takes about 4 hours.
The only FAL options I am using (in the dnetd.conf file) are -ae -r =
/offline
/offline is the exported path.
Standard file copy is fast (I didn't benchmark the system but it looks =
fine). I changed NSP_MAX_WINDOW to 1 in dn.h to improve the performance =
of the file copy (as it was suggested somewhere in the net) but the =
restore performance wasn't improved.

Thank you very much for your time and support.

-----Original Message-----
From: Patrick Caulfield [mailto:pa...@ty...]=20
Sent: Wednesday, April 21, 2004 10:34 AM
To: lin...@li...
Subject: Re: [Linux-decnet-user] Restore performance


On Wed, Apr 21, 2004 at 10:19:42AM -0300, Gustavo M. Boado wrote:
>=20
> Hi. I am trying to backup an OpenVMS system to a Linux box (old=20
> story). I changed the RMS_DEFAULT setting as it's suggested in the=20
> documentation and both backup and restore worked properly, but the=20
> restore process take much longer than the backup (4 hours compared to=20
> 20 minutes). Any idea of what might be happening?

It depends on a few things, principal is whether you are pushing or =
pulling from the Linux box. It's some time since I wrote the code but I =
distinctly remember that the blocking was much more efficient one way =
than another.=20

Also the send windowing in Linux is only implemented in one direction =
too - though I think that only affects phase V nodes in Phase IV =
compatibility.

Can you tell me the commands you are doing? - and if you have any FAL =
options set. often the FAL metadata can drastically improve send times =
because it will block more efficiently. fal -ae is a good default to =
use.
--=20

patrick


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo technologies. Learn everything from fundamentals to system =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Linux-decnet-user mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

Re: [Linux-decnet-user] Restore performance

[Patrick C. <pa...@ty...>]

On Wed, Apr 21, 2004 at 10:19:42AM -0300, Gustavo M. Boado wrote:
> 
> Hi. I am trying to backup an OpenVMS system to a Linux box (old story). I
> changed the RMS_DEFAULT setting as it's suggested in the documentation and both
> backup and restore worked properly, but the restore process take much longer
> than the backup (4 hours compared to 20 minutes). Any idea of what might be
> happening?

It depends on a few things, principal is whether you are pushing or pulling from
the Linux box. It's some time since I wrote the code but I distinctly remember
that the blocking was much more efficient one way than another. 

Also the send windowing in Linux is only implemented in one direction too -
though I think that only affects phase V nodes in Phase IV compatibility.

Can you tell me the commands you are doing? - and if you have any FAL options
set. often the FAL metadata can drastically improve send times because it will
block more efficiently. fal -ae is a good default to use.
-- 

patrick

[Linux-decnet-user] Restore performance

[Gustavo M. B. <gb...@na...>]

Hi. I am trying to backup an OpenVMS system to a Linux box (old story). =
I changed the RMS_DEFAULT setting as it's suggested in the documentation =
and both backup and restore worked properly, but the restore process =
take much longer than the backup (4 hours compared to 20 minutes). Any =
idea of what might be happening?

[Linux-decnet-user] More linux-decnet on SuSE Linux

[Larry B. <ba...@us...>]

I noticed the startup of Postfix failed after I enabled startup of 
linux-decnet.  I found there were many startup errors with similar 
messages (from portmap, ntpd, postfix), like:

postfix[2064]: fatal: inet_addr_local: ioctl SIOCGIFNETMASK: No such 
device

There are also messages like:

modprobe: modprobe: Can't locate module

I modified /etc/init.d/decnet to force linux-decnet to startup after 
the other services:

### BEGIN INIT INFO
# Provides:          decnet
# Required-Start:    $network
# X-UnitedLinux-Should-Start: $portmap xntpd postfix nscd
# Required-Stop:     $network
# X-UnitedLinux-Should-Stop: $portmap xntpd postfix nscd
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: DECnet dnetd daemon
### END INIT INFO

I'm still not sure why the errors occur and if they are gone now.  I 
remember seeing the modprobe errors in Red Hat 8 after installing 
linux-decnet; I just ignored them.  I haven't put my linux-decnet 
server back into service after the upgrade from Red Hat 8 to SuSE 9, so 
I can't tell you yet if things are working as they did before.

Larry Baker
US Geological Survey
650-329-5608
ba...@us...

Re: [Linux-decnet-user] linux-decnet on SuSE Linux

[Patrick C. <pa...@ty...>]

On Thu, Apr 15, 2004 at 01:59:40PM -0700, Larry Baker wrote:
> Below is the DECnet startup/shutdown script, /etc/init.d/decnet, for 
> SuSE Linux Professional 9.0.  (The RPM creates 
> /etc/init.d/init.d/decnet on SuSE.  You can delete it, and the unused 
> /etc/init.d/init.d directory.) 

Thanks, I'll include that in the FAQ and, eventually, in the distribution.
-- 

patrick

[Linux-decnet-user] linux-decnet on SuSE Linux

[Larry B. <ba...@us...>]

Below is the DECnet startup/shutdown script, /etc/init.d/decnet, for  
SuSE Linux Professional 9.0.  (The RPM creates  
/etc/init.d/init.d/decnet on SuSE.  You can delete it, and the unused  
/etc/init.d/init.d directory.)

Also, the interface MAC address is set differently.  In Red Hat,  
MACADDR= is in /etc/sysconfig/network-scripts/ifcfg-eth0.  In SuSE,  
LLADDR= is in /etc/sysconfig/network/ifcfg-eth0.


Larry Baker
US Geological Survey
650-329-5608
ba...@us...


#!/bin/sh
#
# /etc/init.d/decnet
#
# Starts/Stops DECnet processes on SuSE Linux
#
# chkconfig: - 09 91
# description:  DECnet.
# processname: dnetd
# config: /etc/decnet.conf
#
# You can install it using the following command:
#
# chkconfig decnet on
#
### BEGIN INIT INFO
# Provides:          decnet
# Required-Start:    $network
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: DECnet dnetd daemon
### END INIT INFO
#
#  
------------------------------------------------------------------------ 
-----
#
# Daemons to start. You may remove the ones you don't want
#
daemons="dnetd phoned"

# Prefix for where the progs are installed. "make install" puts them
# in /usr, the RPM has them in /usr
prefix=/usr

#
# Interfaces to set the MAC address of. By default only the default  
interface
# in /etc/decnet.conf will be set. If you want to set up more interfaces
# for DECnet, then add them here.
#
extra_interfaces=""

# Source LSB init functions
# providing start_daemon, killproc, pidofproc,
# log_success_msg, log_failure_msg and log_warning_msg.
# This is currently not used by UnitedLinux based distributions and
# not needed for init scripts for UnitedLinux only. If it is used,
# the functions from rc.status should not be sourced or used.
#. /lib/lsb/init-functions

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     be verbose in local rc status and clear it  
afterwards
#      rc_status -v -r  ditto and clear both the local and overall rc  
status
#      rc_status -s     display "skipped" and exit with status 3
#      rc_status -u     display "unused" and exit with status 3
#      rc_failed        set local and overall rc status to failed
#      rc_failed <num>  set local and overall rc status to <num>
#      rc_reset         clear both the local and overall rc status
#      rc_exit          exit appropriate to overall rc status
#      rc_active        checks whether a service is activated by  
symlinks
#      rc_splash arg    sets the boot splash screen to arg (if active)
. /etc/rc.status

# Reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0       - success
# 1       - generic or unspecified error
# 2       - invalid or excess argument(s)
# 3       - unimplemented feature (e.g. "reload")
# 4       - user had insufficient privileges
# 5       - program is not installed
# 6       - program is not configured
# 7       - program is not running
# 8--199  - reserved (8--99 LSB, 100--149 distrib, 150--199 appl)
#
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signaling is not supported) are
# considered a success.

#
# Set up some variables.
#
startcmd="startproc"
stopcmd="killproc"
statuscmd="checkproc"

case $1 in
    start)
      if [ ! -f /etc/decnet.conf ]
      then
        echo "DECnet not started as it is not configured."
        rc_failed 6
        rc_exit
      fi

      # If there is no DECnet in the kernel then try to load it.
      if [ ! -f /proc/net/decnet ]
      then
        modprobe decnet
        if [ ! -f /proc/net/decnet ]
        then
          echo "DECnet not started as it is not in the kernel."
          rc_failed 5
          rc_exit
        fi
      fi

      echo -n "Starting DECnet..."

      NODE=`grep executor /etc/decnet.conf| awk '{print $2}'`
      echo "$NODE" > /proc/sys/net/decnet/node_address
      CCT=`grep executor /etc/decnet.conf | awk '{print $6}'`
      echo "$CCT" > /proc/sys/net/decnet/default_device
      $prefix/sbin/setether $NODE $CCT $extra_interfaces

      for i in $daemons
      do
        $startcmd $prefix/sbin/$i
        rc_status
      done
      rc_status -v
      ;;

    stop)
      echo -n "Stopping DECnet..."
      for i in $daemons
      do
        $stopcmd $prefix/sbin/$i
        rc_status
      done
      rc_status -v
      ;;

    restart|reload|force-reload)
      echo -n "Restarting DECnet..."
      for i in $daemons
      do
        $stopcmd $prefix/sbin/$i
        rc_status
        $startcmd $prefix/sbin/$i
        rc_status
      done
      rc_status -v
      ;;

    status)
      echo -n "Checking DECnet..."
      for i in $daemons
      do
        $statuscmd $prefix/sbin/$i
        rc_status
      done
      rc_status -v
      ;;

    *)
      echo "Usage $0 {start|stop|restart|force-reload|status}"
      ;;
esac

rc_exit

[Linux-decnet-user] Re: DAP , was Hello

[Patrick C. <pa...@ty...>]

On Mon, Apr 05, 2004 at 02:07:23PM -0400, David Mitton wrote:
> 
> Yes, we tried to fix a number of problems post 5.6. Versions 6.0 and v7.0 
> were major upgrades in the protocol.  However, many of changes were not 
> implemented mostly due to interia and backwards compatibility.  VMS would 
> have done the most work, as it was the most active in adding new 
> features.   Though the PATHWORKS (and Ultrix) development did expose issues.
> 
> The latest spec would at least provide insight into the correct approach to 
> problems or encodings not mentioned in v5.6.
> 
> Where do you want the files?


email to my above address would do, if you want an ssh logon I can open up my
public machine - send me an ssh public key.
 
> ...
> >
> >> - I was also the designer/implementor of DECnet-DOS and it's
> >> kernel.  Though the neurons are a bit rusty, I used to do a DECnet socket
> >> programming tutorial at DECUS.  I don't know how well your sockets match
> >> ours, but I may be able to dig up some old material.
> >
> >Actually, one of the DAP incompatibilities is with DECnet/DOS :-)
> 
> Nahh!  Not possible. ;^)
> One of the best NFT implementations out there.
> Seriously, if it's not a bug, maybe it's a mis-understood or undocumented 
> feature.  DEC filesystems can be interesting creatures.

Oh, I'm pretty sure it's a bug on my part. I do some pretty dangerous things
with the CONFIG message to try and make things nice for VMS users and it
wouldn't surprise me if I've overdone it.  I'm also fairly sure that FAL sends
far too may ACKs in some circumstances.

> Another "feature" of DECnet-DOS was that we wrote a DOS block device (disk) 
> driver (NVD) that did a DAP open to a FAL of a file for random access in 
> Block mode or Fixed:512 and created a DOS virtual disk using DAP 
> protocol.   Only drawback is that DOS block operations are not optimised at 
> this level.  Performance could suck big time for disks with large 
> directories.

From what I remember DOS block operations were not optimised at all!
 
> But it worked for simple xfers if you didn't have an SMB server installed.

One thing I wanted to do for Linux, but never got round to it, was a libc
interceptor that took filenames with "::" in them and sent them over the network
to a DAP server so Linux could have proper transparent file access...I may yet
do that but I subsequently worked out just how many library calls I'd have to
intercept :-)


patrick

[Linux-decnet-user] Re: DAP , was Hello

[David M. <da...@mi...>]

On 4/2/2004 08:24 AM +0100, Patrick Caulfield wrote:
>On Thu, Apr 01, 2004 at 01:39:28PM -0500, David Mitton wrote:
> >
> > Hello there,
> >       I've just joined this list, and I don't know how much time I have to
> >       spend on the subject.  But I'd like to offer some help if 
> possible and a
> > few comments.
> >
> > - I see that you've rescued a set of DECnet specs from Matt Thomas.  They
> > are no longer visible on the HP website.
> >
> > I have a copy of DAP 7.3.1 dated 21-April-1995 (in text and .RNO) that I'd
> > be willing to contribute.  You only seem to have V5.6 (which is mostly 
> good
> > enough)
> > I was the DAP Architect for a number of years until Aug 1995
>
>I'd love to see a later DAP specification. There are bugs and missing features
>and some small incompatibilities in FAL that might be cleared up by that...

Yes, we tried to fix a number of problems post 5.6. Versions 6.0 and v7.0 
were major upgrades in the protocol.  However, many of changes were not 
implemented mostly due to interia and backwards compatibility.  VMS would 
have done the most work, as it was the most active in adding new 
features.   Though the PATHWORKS (and Ultrix) development did expose issues.

The latest spec would at least provide insight into the correct approach to 
problems or encodings not mentioned in v5.6.

Where do you want the files?

...
>
> > - I was also the designer/implementor of DECnet-DOS and it's
> > kernel.  Though the neurons are a bit rusty, I used to do a DECnet socket
> > programming tutorial at DECUS.  I don't know how well your sockets match
> > ours, but I may be able to dig up some old material.
>
>Actually, one of the DAP incompatibilities is with DECnet/DOS :-)

Nahh!  Not possible. ;^)
One of the best NFT implementations out there.
Seriously, if it's not a bug, maybe it's a mis-understood or undocumented 
feature.  DEC filesystems can be interesting creatures.

Another "feature" of DECnet-DOS was that we wrote a DOS block device (disk) 
driver (NVD) that did a DAP open to a FAL of a file for random access in 
Block mode or Fixed:512 and created a DOS virtual disk using DAP 
protocol.   Only drawback is that DOS block operations are not optimised at 
this level.  Performance could suck big time for disks with large directories.

But it worked for simple xfers if you didn't have an SMB server installed.

Dave. 

Re: [Linux-decnet-user] Hello

[Patrick C. <pa...@ty...>]

On Thu, Apr 01, 2004 at 01:39:28PM -0500, David Mitton wrote:
> 
> Hello there,
> 	I've just joined this list, and I don't know how much time I have to 
> 	spend on the subject.  But I'd like to offer some help if possible and a 
> few comments.
> 
> - I see that you've rescued a set of DECnet specs from Matt Thomas.  They 
> are no longer visible on the HP website.
> 
> I have a copy of DAP 7.3.1 dated 21-April-1995 (in text and .RNO) that I'd 
> be willing to contribute.  You only seem to have V5.6 (which is mostly good 
> enough)
> I was the DAP Architect for a number of years until Aug 1995

I'd love to see a later DAP specification. There are bugs and missing features
and some small incompatibilities in FAL that might be cleared up by that...
 
> Someone recently gave me a hard copy of a LAT spec.  I needed some info for 
> an IETF RFC reference.  It was interesting that I could not get a complete 
> answer out of the "official" folks.  Seems that LAT is winding down.

LAT I'm happy not to see, for two reasons. 1: It was a pure reverse-engineering
job and I'd like to keep it that way for legal reasons and 2: I'm sure I've
missed a lot out (In fact I know I have as Fred van Kempen told me last year!)
and the code is now such a mess that if I found out how it really worked I'd have
to rewrite it all and I just don't have the time for that !
 
> - I was also the designer/implementor of DECnet-DOS and it's 
> kernel.  Though the neurons are a bit rusty, I used to do a DECnet socket 
> programming tutorial at DECUS.  I don't know how well your sockets match 
> ours, but I may be able to dig up some old material.

Actually, one of the DAP incompatibilities is with DECnet/DOS :-)
 
> - One of the FAQ pages says that "DECnet was designed for the VAX", well 
> I'm sure a few of the contributors could tell you that PDP-11 and 
> DECsystem-10 DECnets predated VMS by a number of years.  Most DEC 
> architectures were little endian.  The VAX by it's heredity continued that.
> 
> - Oh Steve W., I did find a use for raw sockets, to implement MOP functions.
> 
> - I used to like to say I was the last one to implement DECnet Phase-IV, in 
> PathWORKS for Windows 95. (we rewrote my DOS TSR kernel as a protected mode 
> Windows component, because no one else would)
> Now I find that you guys have taken my claim away.  sigh  ;^p
> 

-- 

patrick

Re: [Linux-decnet-user] Hello

[Steven W. <st...@ch...>]

Hi,

On Thu, Apr 01, 2004 at 01:39:28PM -0500, David Mitton wrote:
> 
> Hello there,
> 	I've just joined this list, and I don't know how much time I have to 
> 	spend on the subject.  But I'd like to offer some help if possible and a 
> few comments.
> 
> - I see that you've rescued a set of DECnet specs from Matt Thomas.  They 
> are no longer visible on the HP website.
> 
> I have a copy of DAP 7.3.1 dated 21-April-1995 (in text and .RNO) that I'd 
> be willing to contribute.  You only seem to have V5.6 (which is mostly good 
> enough)
> I was the DAP Architect for a number of years until Aug 1995
>
That would be interesting to look through, although right now I don't
have a lot of time to work on this - as you can probably tell by the
lack of recent patches :-)

> Someone recently gave me a hard copy of a LAT spec.  I needed some info for 
> an IETF RFC reference.  It was interesting that I could not get a complete 
> answer out of the "official" folks.  Seems that LAT is winding down.
> 
> - I was also the designer/implementor of DECnet-DOS and it's 
> kernel.  Though the neurons are a bit rusty, I used to do a DECnet socket 
> programming tutorial at DECUS.  I don't know how well your sockets match 
> ours, but I may be able to dig up some old material.
> 
> - One of the FAQ pages says that "DECnet was designed for the VAX", well 
> I'm sure a few of the contributors could tell you that PDP-11 and 
> DECsystem-10 DECnets predated VMS by a number of years.  Most DEC 
> architectures were little endian.  The VAX by it's heredity continued that.
> 
> - Oh Steve W., I did find a use for raw sockets, to implement MOP functions.
>
We have packet sockets for this though under Linux, so I guess they
are still pretty redundant ...

> - I used to like to say I was the last one to implement DECnet Phase-IV, in 
> PathWORKS for Windows 95. (we rewrote my DOS TSR kernel as a protected mode 
> Windows component, because no one else would)
> Now I find that you guys have taken my claim away.  sigh  ;^p
> 
> Dave.
> 
>
:-) I'm told that our version is the only multithreaded DECnet stack
but I'm not 100% certain to claim that. I'd like to have a go and clean
up some more of the code at some stage and add one or two extra
features: zero copy for example.

Its always good to hear from another implementor of DECnet
as hints and advice are always welcome. If you want to take up
one of the outstanding tasks, please feel free :-)

Steve.

[Linux-decnet-user] Hello

[David M. <da...@mi...>]

Hello there,
	I've just joined this list, and I don't know how much time I have to spend 
on the subject.  But I'd like to offer some help if possible and a few 
comments.

- I see that you've rescued a set of DECnet specs from Matt Thomas.  They 
are no longer visible on the HP website.

I have a copy of DAP 7.3.1 dated 21-April-1995 (in text and .RNO) that I'd 
be willing to contribute.  You only seem to have V5.6 (which is mostly good 
enough)
I was the DAP Architect for a number of years until Aug 1995

Someone recently gave me a hard copy of a LAT spec.  I needed some info for 
an IETF RFC reference.  It was interesting that I could not get a complete 
answer out of the "official" folks.  Seems that LAT is winding down.

- I was also the designer/implementor of DECnet-DOS and it's 
kernel.  Though the neurons are a bit rusty, I used to do a DECnet socket 
programming tutorial at DECUS.  I don't know how well your sockets match 
ours, but I may be able to dig up some old material.

- One of the FAQ pages says that "DECnet was designed for the VAX", well 
I'm sure a few of the contributors could tell you that PDP-11 and 
DECsystem-10 DECnets predated VMS by a number of years.  Most DEC 
architectures were little endian.  The VAX by it's heredity continued that.

- Oh Steve W., I did find a use for raw sockets, to implement MOP functions.

- I used to like to say I was the last one to implement DECnet Phase-IV, in 
PathWORKS for Windows 95. (we rewrote my DOS TSR kernel as a protected mode 
Windows component, because no one else would)
Now I find that you guys have taken my claim away.  sigh  ;^p

Dave.