home *** CD-ROM | disk | FTP | other *** search
/ Internet Publisher's Toolbox 2.0 / Internet Publisher's Toolbox.iso / internet / email / pegasus / mercury / importan.t!! < prev    next >
Encoding:
Text File  |  1993-11-26  |  5.0 KB  |  102 lines
  1. ┌────────────────────────────────────────────────┐
  2. │    Form number problems                        │
  3. └────────────────────────────────────────────────┘
  4.  
  5. At some stage during the development life of CLIB.NLM, Novell made
  6. arbitrary changes to some of the NetWare API calls which access and
  7. create jobs in NetWare queues. For no apparent reason, and without
  8. warning to developers, they altered some of the routines so that they
  9. swapped the order of bytes in the "form number" field of the job
  10. record. Older versions of Mercury required the use of confusing JOB
  11. statements in MERCURY.INI to correct the CLIB changes, but Mercury
  12. 1.11 includes internal logic to detect offending CLIB versions and
  13. correct the values automatically. JOB numbers needed by older
  14. versions of Mercury are therefore obsolete and possibly a nuisance,
  15. so Mercury 1.11 ignores them. Furthermore, if you choose to use
  16. Mercury's file-based spooler submission mechanism, the problem
  17. becomes completely irrelevant.
  18.  
  19. It is still imaginable, however, that you may encounter a version of
  20. CLIB where Mercury cannot make the appropriate adjustments to the
  21. Form numbers, so the ability to remap the form numbers Mercury uses
  22. is still implemented using FORM statements in MERCURY.INI. The most
  23. obvious symptom that you might need to use these statements is the
  24. appearance of jobs in the mailqueue with strange job numbers like
  25. 25856 or 28160. You can tell at a glance whether this problem is
  26. occurring on your system by running PCONSOLE and examining the mail
  27. queue. All jobs in the list should be either form type 101 or form
  28. type 110. If you see other form numbers then you have the problem.
  29. NOTE: PCONSOLE only shows the first four digits of the form number in
  30. the queue list - to see the whole form number, you must select a job
  31. and press <Enter> to see its full description.
  32.  
  33. The form numbers Mercury uses when scanning for and creating jobs in
  34. the NetWare mail queues can be adjusted on a module-by-module basis
  35. using FORM statements in the module's definition section in 
  36. MERCURY.INI. The form statements take the following forms:
  37.  
  38. FORM1:  Defines the value the module should use when SCANNING for
  39.         jobs to service. Mercury.NLM scans for jobs of type 101,
  40.         MercuryC.NLM scans for jobs of type 110 and MercuryS.NLM
  41.         does no scanning at all.
  42.  
  43. FORM2:  Defines the form number the module should use when CREATING
  44.         a job to be processed by MercuryC.NLM - that is, outgoing
  45.         mail. Only Mercury.NLM uses this value, which defaults to
  46.         110.
  47.  
  48. FORM3:  Defines the form number the module should use when CREATING
  49.         a job which should be examined by Mercury.NLM (that is, any
  50.         mail which is definitely for local delivery, or where the
  51.         local/nonlocal status is unknown). The usual value for this
  52.         field is 101. MercuryS.NLM uses this value to create jobs
  53.         for any incoming mail. Mercury.NLM and MercuryC.NLM use this
  54.         value when creating delivery failure and other notifications,
  55.         and the mail server always creates jobs using this value.
  56.  
  57. Using form definitions is fairly straightforward; find the incorrect
  58. job number which is appearing in the mail jobs in the queue, and
  59. determine the source of the job in the queue using the information
  60. in the sections above, and by following a job through its life in
  61. the queue using PCONSOLE. Create FORMx entries as appropriate in the
  62. offending module's section in MERCURY.INI using the incorrect number
  63. as the value.
  64.  
  65. Examples:
  66.  
  67. * Mercury.NLM is accepting mail from PMail with job type 101, but
  68.   is creating outgoing mail with the job type 28160, and is creating
  69.   delivery failure notifications with the job type 25856
  70.  
  71.   -- The job type Mercury.NLM scans for is OK, so there's no need for
  72.   -- a FORM1 field. The outgoing mail has the wrong number, so we need
  73.   -- to add a FORM2 field, and because delivery failures are local
  74.   -- mail we deduce that we also need a FORM3 field. The following
  75.   -- lines need to be added to MERCURY.INI in the [MERCURY] section:
  76.   --
  77.   -- FORM2: 28160
  78.   -- FORM3: 25856
  79.  
  80. * MercuryC.NLM is processing outgoing mail without any trouble, but
  81.   delivery failure notifications are going into the mail queue with
  82.   the form number 25856; as well, MercuryS.NLM is creating all
  83.   incoming mail with form number 25856.
  84.  
  85.   -- Both NLMs are creating local mail, so the FORM3 field in each
  86.   -- NLM's section in MERCURY.INI needs to be adjusted. The following
  87.   -- line would be added into each NLM's section:
  88.   --
  89.   -- FORM3: 25856
  90.  
  91.  
  92. I stress that it should not in general be necessary to use this form
  93. remapping capability: Mercury 1.11 has been tested with NetWare 3.11
  94. (using several versions of CLIB.NLM), NetWare 3.12 and NetWare 4.01
  95. and its internal correction logic has been found to work correctly on
  96. all these versions. This information is provided only as a hedge
  97. against future changes by Novell.
  98.  
  99. If you encounter form-number problems with Mercury 1.11 please contact
  100. the author by Internet e-mail to david@pmail.gen.nz.
  101.  
  102.