> what did you find out?   
      
    JE> Sorry for the delay, I was called away on business, that pesky work   
    JE> always seems to get in the way!    
      
   ain't that always the way it is? :)   
      
    JE> 1.msg is a normal file attach message from 1 of the   
    JE> doors. There is a file in the OUT folder called lastread which   
    JE> would be the high water mark.    
      
   right... some systems use 1.msg (eg: dbridge) while others use lastread or   
   similar...   
      
    JE> I watched the folder while a connectiong was made. I see that as   
    JE> usual at midnight all files are sent. As files were being received,   
    JE> the batch file runs that imports the door files, and creating new   
    JE> outbound files at the same time. This is where 1.msg was coming   
    JE> from.   
    JE> As a result, 1.msg was sent in this same connection as the batch   
    JE> completed before the connection to the hub did. So when you look at   
    JE> the out folder after everything has completed, 1.msg is missing   
    JE> (already sent) and 2.msg and so on are there. Hmmmm....   
      
   ahhh... ok... and something is packing those MSGs into ?UT or ?LO files...   
   that sounds proper...   
      
   [chomp]   
      
    JE> I checked all the doors, they are set to Binkley (BRE, TAL, FE,   
    JE> AB1, AB2, GAC  BJ, FC & WH). Do they need to be re-stalled to get   
    JE> set right?    
      
   if they are set to binkley style, then everything should be ok, AFAIK... it   
   doesn't sounds like there is any problems now that you've figured out where   
   1.msg was going and when... if the games' packets are coming in and going out   
   with proper processing, you should be ok as you are... at least from the   
   sounds of things so far ;)   
      
   )\/(ark   
      
   ---    
    * Origin:  (1:3634/12.42)