SH>>   Okay then I'm not out to lunch. :)  I just mis-read
 SH>> what you said.  I've almost got an updated MFM with
 SH>> file_id.diz importing working, just being held up by
 SH>> time removing the fossil / door code to MFM which is
 SH>> causing a giant headache in the OS/2, Win32 port.

 MvanL> Man I just use the Hurl menu option.

what has that to do with removing fossil and door library code from the
package in question? hurl is used to move a file from one location to
another along with its description... that has nothing to do with the
original question and discussion about MFM importing file_id.diz files...

[Arrowbridge I]

 MvanL>> Probably because it's looking for dorinfo2.def for node 2 etc.
 MvanL>> Atleast that's how AB-I works ie. dorinfo.def.
I'm assuming
 MLvan>> AB-II works similarly.

 SH>>   Exactly.

 MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def

that is exactly how one does it with a system that doesn't create
dorinfo2-9 files... now, what does one do when they are running 10 or more
nodes? the dorinfox.def standard wasn't thought thru very well... i've seen
implementation that use hex and as such can support up to 16 nodes... i've
also seen implementations that support base36 which is also limiting on a
large multinode system... then, there're those that start dropping letters
to make room for numbers...

  ie: dorinfo1.def
      dorinf22.def
      dorin134.def

like i say, not very well thought out... but it is way way way too late to
do anything about it now, too... i tried some 15 years back but all anyone
wanted to do then was spout the existing standard and do nothing about
fixing or enhancing it...

[trim]

 MvanL>> Apparently people adopted the numeral in dorinfo#.def to
 MvanL>> be a node designator when it was never meant to be. It's
 MLvan>> probably a "dorinfo" dropfile specification version number.

hunh? you can provide documentation to this? i'd like to read it because
nothing like it was ever presented or found in all my research years ago...
everything i found showed that the number _was_ the node number... some bbs
systems got around the 9 node limitation by creating dorinfo1.def for all
nodes, though... and that's no real problem if the door can look in a
directory other than its own for the drop file...

  ie: somedoor c:\bbs\n1

where c:\bbs\n1 is where the dropfile, whatever is being used, is
located... c:\bbs\n42 for node 42... no copying or overwritting and no
possibility of things going wonky if two users enter the door at the same
time...

)\/(ark