home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 3 Comm / 03-Comm.zip / faxd_071.zip / CHANGES.071 next >
Text File  |  1997-04-03  |  7KB  |  151 lines
  1. CHANGES in V03
  2.  
  3. Besides cosmetic changes, v03 addresses the problem that some OS/2
  4. sendmail commands require '-a' and some, '-af' in the command line.
  5. A line is added to the faxd.cfg file.  The default is:  '-a'.  If you
  6. need -af, then just add the 'f'.  No quotation marks needed.
  7.  
  8.  
  9.  
  10. CHANGES IN V04
  11.  
  12. I decided to use semaphores instead of data queues for event
  13. triggering between and among threads.  This means that you will have
  14. to install the REXXIPC.DLL (included in an internal ZIP file) in your
  15. OS2/DLL directory.
  16.  
  17. I split the email thread off as a third working thread (in addition
  18. to the main thread and the clock thread).  It will eventually handle
  19. other notification chores -- involving error handling.
  20.  
  21. I added four displays to the main thread's window:  a clock tick
  22. indicator and three "lights" for the three semaphores.  These
  23. indicators are probably temporary -- so that I can watch what is
  24. happening when I make changes.  They add overhead.
  25.  
  26. I began building some exception handling into the worker threads.
  27. Missing file names or fax numbers ought to result in the skipping and
  28. renaming of the file being worked on.  (The last letter is changed to
  29. an underscore.)  Over time, as I identify things that stop a thread,
  30. I will try to catch them before they happen.
  31.  
  32. I also built in a thread kill and restart facility for each of the
  33. three worker threads.  At the designated intervals, the main thread
  34. "posts" the worker thread's semaphore.  That triggers the worker
  35. thread to do its job.  The worker thread also "resets" the semaphore.
  36. If the main thread notices during subsequent cycles that the
  37. semaphore has not been reset, it waits for a few cycles and then
  38. kills the thread, renames the current file it was working on and
  39. restarts it.  The number of cycles it waits is (rounded down to the
  40. next whole number)
  41.  
  42. For thread 1:  20 divided by the number of ten second tics in a
  43. cycle.
  44.  
  45. For thread 2:  10 divided by the number of ten second tics in a
  46. cycle.
  47.  
  48. For thread 3:  Twice the number for thread 2.
  49.  
  50. The idea is to give a process time to complete before panic sets in.
  51.  
  52. The three semaphore lights keep track of the progress.  Yellow means
  53. that the threads are in an unknown condition or in transition.  The
  54. program starts in yellow.  Green means the thread is posting and
  55. resetting normally.  The light comes on (lighter green) when the post
  56. is sent by the main thread.  It goes off when the reset is sent
  57. (there is a small built in delay).  If a reset is missed, it goes to
  58. yellow and begins to keep count of the missed cycles.  Next it goes
  59. to red.  It flashes on (lighter red) at the post events.  A big fax
  60. and a short cycle can easily send the Sem1 light into the red.  But
  61. there ought to be plenty of headroom.
  62.  
  63. I am not sure what error codes Sendmail returns.  If FAXD does not
  64. get a '0' from Sendmail, it renames the email file.
  65.  
  66. The next version will probably increase the amount of exception
  67. handling and include notification that a "job" has been rejected or
  68. that it has caused thread death.  At the moment, it just leaves the
  69. carcass of the offending job in the directory.
  70.  
  71. FXFTP.EXE has also been changed a bit.  I added a button to preview
  72. the fax or file.  You have to add another line in the FXFTP.CFG file
  73. with the command to launch the viewer app.  For example:
  74. d:\faxworks\faxworks.exe.  the program issues this command followed
  75. by the file name.  You can also use:  start d:\faxworks\faxworks.exe
  76. to get rid of the command session.  Or you can use another program,
  77. like SPView or Review.  If you edit the file in FaxWorksand resave
  78. it, however, you will have toopen the new fax under the new number.
  79.  
  80. CHANGES IN V07
  81.  
  82. Lots of changes!
  83.  
  84. The Configuration file has changed.  The 6th and 7th lines now are in
  85. SECONDS and refer to minimum and maximum interval for activity.
  86.  
  87. Only the Thread that checks for Envelope files is active on launch.
  88. the other two are quiet -- reflected by Yellow lights on the control
  89. panel.  They become active only while there is an active job.  This
  90. cuts down on overhead.
  91.  
  92. The program starts by checking at intervals as set by the minimum
  93. interval number in the config file -- line 6. Over two hours, it
  94. increases this to the interval set by line 7. As soon as a job is
  95. detected, however, it resets to the most frequent and starts the
  96. process over.  I think of the longer setting as the interval I want
  97. it to use in the background under normal circumstances.  The faster
  98. pace is like one's heart speeding up when there is activity.
  99.  
  100. I have modified the thread restart feature.  It now counts up to a
  101. number that is based on the interval being used and the number of
  102. jobs the first thread was working on.  The busier the program, the
  103. more time will elapse before it decides a thread has crashed.
  104.  
  105. The program now sends out email messages informing you that a file
  106. has caused an error or has crashed a thread.
  107.  
  108. I changed the way Semaphores worked to allow multiple instances on
  109. one machine.  Run each one is a separate directory!  With its own
  110. config file.
  111.  
  112. FaxD tries to keep itself up and running by monitoring its threads
  113. and restarting them if needed.  I intend this for long unattended
  114. operation.  So I also wrote a small program to launch FaxD and
  115. monitor its status.
  116.  
  117. FaxDGo is basically a loop.  It starts FaxD and waits for it to
  118. close.  When FaxD closes, FaxDGo loops around and restarts it.  What
  119. makes FaxDGo a bit different, is that it also starts a thread to
  120. monitor FaxD.  It uses an interprocess queue -- with a name based on
  121. its own PID -- to check on FaxD.  This takes place in the main thread
  122. of FaxD in the off clock cycles -- the ones where no processing took
  123. place.  It supplies FaxD with the Queue name at launch time.  If FaxD
  124. sees the queue name, it checks the queue every ten seconds and, if
  125. the queue is empty, it places its PID in it.  At the other end, the
  126. monitor stores the PID and checks every minute by emptying the queue
  127. and rechecks on the next cycle.  If the queue is empty, FaxDGo, after
  128. a few 5 second rechecks, kills the FaxD PID and restarts FaxD.
  129.  
  130. There have been some last minute changes to FaxDGo to allow
  131. running multiple instances, and the revisions have not been 
  132. tested.
  133.  
  134. Now, the problem is trying to get rid of FaxD.  It just will not go
  135. away if started with FaxDGo.  So, I include a CMD file called
  136. FaxDStop.CMD.  Until you run FaxDGo, this command file is not
  137. functional.  Each time you run FaxDGo, it changes FaxDStop by
  138. inserting its PID in the REXX file.  Don't rename it! Running 
  139. FaxDStop kills FaxDGo and FaxD.
  140.  
  141. Except for debugging and logging, this is as far as I want to go with
  142. this project.  I am, however, rewriting the whole thing using Object
  143. Rexx as my next project. 
  144.  
  145. CHANGES V071
  146.  
  147. OOPS! Left debugging code in FaxDGo. Only this file needs to be 
  148. updated.
  149.  
  150.  
  151.