Hi Kees,

Friday May 24 2013 23:44, you wrote to me:

 KE> Hello Ulrich!
 KE> 24 May 13 20:51, you wrote to me:
 KE>
 KE>  If Bob is using the latest available precompiled version of makenl
 KE> for OS/2, it will probably be from the MN331O16.ZIP or the
 KE> MN331O32.ZIP as present on a.o.
 KE> http://sourceforge.net/projects/makenl/files/3.3.1/
 KE>
 KE>  could you try those two as well ?

in the meantime I've got an OS32(32-bit) compile passed with OpenWatcom 1.9

With this OS/2 (32-bit) version of rev 3.3.3 code I can reproduce the crash
reported  =:)
long detailed report you'll find under

=>   https://sourceforge.net/p/makenl/bugs/17/

In summary .. its not about Allowunpub or other parameters ...
The routine crashes after the segments are compiled and makenl tries
to find the highest message number (~ SearchMaxMSG)
The difference between the DOS revision (reg56-1.log) and the OS2 revision
(reg56.log) you'll find in the report
the reg56-1.log shows, that there are much more steps outstanding until makenl
will finish with success ...

success:
========
[...]
d 24-May-2013 23:43:41 makenl[1850] Skip arc for r:\makenl\region56.144
d 24-May-2013 23:43:41 makenl[1850] OpenMSGFile entered
d 24-May-2013 23:43:41 makenl[1850] OpenMSGFile: 2:292/854
filename=r:\makenl\region56.144
d 24-May-2013 23:43:41 makenl[1850] SearchMaxMSG(r:\makenl\NETMAIL)
d 24-May-2013 23:43:41 makenl[1850] myfnmerge: drive='(null)' dir='(null)'
name='*' ext='msg'
d 24-May-2013 23:43:41 makenl[1850] SearchMaxMSG: path=r:\makenl\NETMAIL,
result=5
d 24-May-2013 23:43:41 makenl[1850] OpenMSGFile: MSGnum is set to 5
[...]

crashed:
========
[...]
d 25-May-2013 03:19:38 makenl[259] Skip arc for l:\makenl\region56.151
d 25-May-2013 03:19:38 makenl[259] OpenMSGFile entered
d 25-May-2013 03:19:38 makenl[259] OpenMSGFile: 2:292/854
filename=l:\makenl\region56.151
d 25-May-2013 03:19:38 makenl[259] SearchMaxMSG(l:\makenl\NETMAIL)
d 25-May-2013 03:19:38 makenl[259] myfnmerge: drive='(null)' dir='(null)'
name='*' ext='msg'
[CRASHED]

From my experiences in last year (rev 3.2.6 ff.) problems, I've still
identified a stack pointer problem caused by the OpenWatcom 1.9 compiler and
the used code
with the OpenMsgFile routine  (msgtool.c l.160)
  FixStack = NULL;    /* BUGFIXED 2012-06-28 us filepointer/stack fix */

The story behind was:
once calling the logwrite() routine (in mklog.c) the pointer gets garbaled
open logfile works, but on return the still opened msgfile pointer has been
changed (!!) and no longer points to the original filepointer, so therefor
makenl terminated with "cannot open message file" because the filepointer
was used for writing the log  :-P
Markus digged into this problem and found the Stackpointer problem

My current "feeling" is, that this is another stack pointer problem in another
area of the code while switching between routines



 KE> Kees

regards, uli   ;-)

---
 * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)