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