On Thu, 06 Mar 2014, Kurt Weiske wrote to All:   
      
    KW> I've had sporadic issues with ALLFIX version 6.0.24 -- it'll work   
    KW> for a couple of weeks, then it'll hang, with nothing in the log. Is   
    KW> there anything I can do to debug this?   
      
   what OS?   
      
   i know that v6 has had some changes and fixes added to it but the only thing i   
   can relate to is what was happening on my system with my 5.13.4 universal...   
   that being that if one of my frontdoor nodes was rescanning the netmail folder   
   at the same time that allfix was, allfix would lockup if it ran across the   
   same message that the FD node was on... in programmer speak, this was likely   
   to be because allfix was not opening the messages in compatibility mode...   
   that meaning that it was trying to open the message in a deny mode where no   
   other tools could access the message... i don't remember when i finally   
   figured this out but when i finally did figure out that it was allfix, i moved   
   all my TIC file processing to be done during midnight maintence when the   
   mailer nodes were all down...   
      
   later on, i had to upgrade from my reliable OS/2 Warp 3 to eCS and allfix was   
   locking up again... in some cases, completely locking the entire system...   
   now, mind you, even though i have the universal flavor of allfix, i was   
   running it completely on the DOS side of my setup... on a whim, i tried   
   running it from the OS/2 side and it worked without locking up! there have   
   been times when it or my OS/2 binkd have locked up and it has turned out to be   
   a conflict of some sort to do with the EMX libraries that both were compiled   
   with... i figured this out because i could close one or the other of the two   
   and the other one would take off finishing its processing... that points to a   
   race condition... probably trying to acquire some semaphore or pipe... i don't   
   know... what i did find out was that i could run another OS/2 flavor of binkd   
   and avoid the problem... that being the klibc flavor... both binkd/2s are   
   named the same because no one on the binkd team has seen fit to name the klibc   
   one differently in the make files and it is very easy for me to figure out   
   when i have updated to the wrong flavor because it or allfix will jam up on   
   me... change the flavor of binkd and we're back to running properly...   
      
   i should also note that my setup is geared to the frontdoor layout and   
   operating methods... my binkd stuff mainly uses fileboxes which are managed by   
   my inbound and outbound scripts (4DOS/4OS2 BAT/BTM/CMD files)... allfix (the   
   main one) has no clue about binkd being on the system... i say "the main one"   
   because i do have a secondary instance strictly for handling FREQs that come   
   in via binkd... it is an exact copy of the main allfix with a couple of paths   
   and file names changed as well as the mailer setting being altered to whatever   
   BSO allfix knows about... it works great and i only need to update the FIX and   
   IDX files in the bink allfix every once in a while... that mainly after adding   
   a new node or making any files areas changes... SETUP.FIX and SETUP.IDX are   
   not copied over when i do this update, though... that would mean that i have   
   to go back in and adjust the paths, file names and mailer settings again as   
   well as reenabling the FREQ processor...   
      
   i know this may not help you with your situation but it may help you in   
   finding out if the lockups you are having are comping from the netmail area   
   processing if your mailer is also scanning the netmail area at the same   
   time... at least, IME, that's the first place i would look...   
      
   oh yeah, yes, the OS/2 side of my allfix universal doesn't have the same   
   netmail area scanning problem as the DOS side... this is understandable   
   considering that the universal flavor has separate internal binaries for each   
   OS flavor allfix runs on... they're all just packaged in one large binary with   
   a special jump table at the beginning of the executable that determines which   
   flavor needs to be used ;)   
      
   )\/(ark   
      
    * Origin:  (1:3634/12)