$MAIL routines, PURGE/RECLAIM ->-CONV-F-OPENIN, error opening

[Ruslan R. Laishev]

Hello, All!

I have s some trouble with understanding what is a reason of so diagnostic?

%CMA-F-EXCCOPLOS, exception raised; some information lost
-CONV-F-OPENIN, error opening !AS as input
-RMS-F-IFI, invalid internal file identifier (IFI) value
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL 0 0000000000013830 FFFFFFFF80C3D830
LIBRTL ? ?
PTHREAD$RTL 0 00000000000428D8 000000007BCDE8D8
PTHREAD$RTL 0 0000000000069B6C 000000007BD05B6C
%MAIL-E-NOTEXIST, folder !AS does not exist
PTHREAD$RTL 0 000000000006A9A8 000000007BD069A8
PTHREAD$RTL 0 000000000003CC18 000000007BCD8C18
PTHREAD$RTL 0 000000000003C874 000000007BCD8874
PTHREAD$RTL 0 000000000006D10C 000000007BD0910C
0 FFFFFFFF8015EDA4 FFFFFFFF8015EDA4
0 FFFFFFFF8009EAD0 FFFFFFFF8009EAD0
MAILSHR 0 0000000000040A9C 000000007B716A9C
MAILSHR 0 000000000004134C 000000007B71734C
MAILSHR 0 000000000003E4F0 000000007B7144F0
MAILSHR 0 000000000003E88C 000000007B71488C
MAILSHR 0 00000000000410C4 000000007B7170C4
MAILSHR 0 00000000000412C8 000000007B7172C8
MAILSHR 0 0000000000041A1C 000000007B717A1C
MAILSHR 0 000000000003E184 000000007B714184
MAILSHR 0 0000000000030C44 000000007B706C44
MAILSHR 0 000000000003116C 000000007B70716C
...

A piece of code where is PURGE/RECLAIM action and called:

...
ile3 in_lst[] = {
{0,MAIL$_MAILFILE_FULL_CLOSE,0,0},
{0,MAIL$_NOSIGNAL,0,0},
{0,0,0,0}};
...

mail$mailfile_close (&ctx->pop3ctx$l_mfile,&in_lst,nullist))) )
...



So, is there some specific conditions which I'm need to check before calling mailfile_close with PURGE/RECLAIM ?


TIA.

[Marc Van den Broeck]

I guess you connect to your mailbox and then you do not change to another folder.
If so, you have default folder MAIL where new mails are put in.
But if there are no new mails, the folder MAIL does not exist. (You can easily check that with the Mail utility).
And if the folder this not exist, you will get the kind of error you are experiencing.

Rgds
Marc

[Ruslan R. Laishev]

Hi, Marc!

The "folder" it's just a record in the MAIL.MAI file, but you can see RMS error related to the file operations but not the record.

"%MAIL-E-NOTEXIST, folder !AS does not exist" it's a message wrote by another thread, the app - is muthithreaded.

[Hein van den Heuvel · Accepted solution]

>> So, is there some specific conditions which I'm need to check before calling mailfile_close with PURGE/RECLAIM ?

Uh... make sure that no other thread is calling MAIL$ by making user you are in the main process thread? I do not expect MAIL$ to be thread-safe even though it is not explicitly documented to be unsafe.

Personally I would avoid activating CONV/RECLAIM at all cost, ever. Not just for mail. This is mostly because CONV/RECLAI is not chared. If you have to go exclusive access then IMHO it is better to just to a full convert which will not take much longer and is likely to do a better job.

In a process managing mail I think that mean to stop using MAILFILE_FULL_CLOSE.
I woudl start using MAIL$MAILFILE_PURGE_WASTE, but without the MAILFILE_RECLAIM. This will just deleted the RMS records with the "WASTEBASKET" alternate key and any message extention files associated with those records.
You then might call MAIL$MAILFILE_COMPRESS occasionally, but again IMHO, I would prefer an outside maintenance procedure calling CONV$CONVERT or using the CONVERT Utility directly and passing a reasonably tuned FDL file for the mail usage in question. (select from a small, medium or big layout perhaps).

Just an opinion (from a guy that maintained CONV/RECLAIM for a while :-).

Hein.

[Ruslan R. Laishev]

Hello, Hein!

Thanks for the oppinion... The mail$mailfile_close is calling from the main thread especially to exclude thread-unsafe nature of the routine.

Thanks.

[Ruslan R. Laishev]

Hi All!

Finally, I removed MAIL$_MAILFILE_FULL_CLOSE option, doing mailfile_close/end, and after that do conv$reclaim().


Thanks to all!

[Ruslan R. Laishev]

Hello again All!


Some other thing must be using in multithreaded environment because MAIL$*_BEGIN routines is not the thread safe. So, calling the MAIL$*_BEGIN routines must be framed with "pthread_mutex_lock" "pthread_mutex_unlock" calls.

Just for your information.