TCPIP 5.5 IMAP Server nonexistent stability

[Stephen Eickhoff_1]

The TCPIP 5.5 IMAP server is unstable even with only two users on the system. It crashes repeatedly with even one user attached. The SYSTEM mailbox is clogged with messages like these:
---------------
From: TCPIP$IMAP
To: SYSTEM
CC:
Subj: JSBACH - %SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH, PC=!XH, PS=!XL


The TCP/IP IMAP server has experienced a runtime error. The reason
for the error should appear on the subject line of this message.

Please investigate this problem as quickly as possible.
Thank you.

------------------
Here is the TCPIP$IMAP account. Careful reading, rereading, and rerereading has not revealed to me whether any of these settings could possibly be insufficient on a two-user mail system:
-----------------------

Username: TCPIP$IMAP Owner: TCPIP$IMAP
Account: TCPIP UIC: [3655,11] ([TCPIP$AUX,TCPIP$IMAP])
CLI: DCL Tables: DCLTABLES
Default: SYS$SYSDEVICE:[TCPIP$IMAP]
LGICMD: LOGIN
Flags: Restricted
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
Primary 000000000011111111112222 Secondary 000000000011111111112222
Day Hours 012345678901234567890123 Day Hours 012345678901234567890123
Network: ##### Full access ###### ##### Full access ######
Batch: ----- No access ------ ----- No access ------
Local: ----- No access ------ ----- No access ------
Dialup: ----- No access ------ ----- No access ------
Remote: ----- No access ------ ----- No access ------
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: 90 00:00 Pwdchange: (pre-expired)
Last Login: (none) (interactive), 17-JUN-2006 23:44 (non-interactive)
Maxjobs: 0 Fillm: 1100 Bytlm: 700000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 2048 JTquota: 4096
Prclm: 8 DIOlm: 1024 WSdef: 20000
Prio: 6 ASTlm: 2448 WSquo: 40000
Queprio: 4 TQElm: 20 WSextent: 40000
CPU: (none) Enqlm: 3000 Pgflquo: 850000
Authorized Privileges:
NETMBX TMPMBX
Default Privileges:
NETMBX TMPMBX

-------------------

The run log looks like this:

-------------------
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
TCPIP-I-IMAPSTART, Server starting.
TCPIP-I-IMAPIDENT, IMAP Server V5.3-RG40
TCPIP-I-IMAPRUN, Server running.
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000007AE42B, PC=00000000000DFAB4, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
00000000007AE42B
00000000000DFAB4
000000000000001B

Register dump:
R0 = 00000000007ADF28 R1 = 0000000000000001 R2 = 000000000002FEB0
R3 = 00000000007ADF28 R4 = 0000000000038A98 R5 = 0000000000000016
R6 = FFFFFFFFFFFFFFFF R7 = 0000000000000000 R8 = 0000000000000003
R9 = 0000000000000002 R10 = 0000000000000001 R11 = 0000000000792750
R12 = 000000000004A570 R13 = 000000000004C800 R14 = 000000000079274C
R15 = 0000000000000000 R16 = 00000000007ADF28 R17 = 00000000000389F8
R18 = 000000000004D798 R19 = 000000007359A5DD R20 = 0000000000000001
R21 = 0000000000000000 R22 = 00000000F00D0001 R23 = 00000003DB380280
R24 = FFFFFFFFF00D5A01 R25 = 0000000000000002 R26 = 000000000004D798
R27 = 0000000000000000 R28 = FFFFFFFF80A65560 R29 = 000000000137EE60
SP = 000000000137EE60 PC = 00000000000DFAB4 PS = 200000000000001B
%SET-W-NOMSG, Message number 007769A8
TCPIP$IMAP job terminated at 17-JUN-2006 23:45:43.20

Accounting information:
Buffered I/O count: 5156 Peak working set size: 29632
Direct I/O count: 7170 Peak virtual size: 208032
Page faults: 2672 Mounted volumes: 0
Charged CPU time: 0 00:00:03.55 Elapsed time: 0 00:04:35.51

---------------

I have tried enabling trace, but it doesn't even indicate when these crashes occur.

Even when the server doesn't crash entirely, it is very unstable. My best interpretation of the documentation is that the server has memory leaks and has been patched to work around them by periodically creating new processes. It seems that when it does this, it silently stops communicating with the client for "up to five seconds." Mozilla Thunderbird does not like this and sometimes either fails to refresh a folder or shows a blank folder. Twiddling Max-Connections from 25 to 50 to 100 to 10 and even 1 doesn't make a difference other than making the glitches change slightly in frequency.

IMAP also creates new versions of emails-- emails which have not been modified by the user. This causes the email directory to become more cluttered and IMAP even slower (and it is already quite slow with more than 40 or 50 messages in a folder). I must periodically purge these files, which can number in the hundreds within a month.

Is there anything I can do to get basic stability out of this product, or should I move to the byzantine but allegedly stable PMDF?

[Stephen Eickhoff_1]

I have ECO 1 installed.

Research into older threads finds that IMAP broke in one of the 5.4 ECOs, but I can't even download any of the earlier 5.4 ECOs from anywhere and use the image just to see if it works.

[Jerry Alan Braga · Accepted solution]

I had ths same problem as well but I got some a special image that has fixed the crashing and stability problem. As far as the creating new message I am not aware of that. If you like I can send you my image. I am also running tcpip 5.5 with ECO1 and the image is a patch for that version.
Just send my a note: jabraga
atsign flanagan dot ca

[John Gillings]

Jerry,
Please don't forward engineering "hotfix" images to others. They haven't been through the normal QA processes and the intention is that engineering and services can track where they are in case problems are discovered.

Treat them like a prescription drug. By all means refer someone you think may have the same symptom to the doctor who prescribed it to you, but please don't just give them your treatment.

Stephen, to have your symptom diagnosed, and possibly obtain the same image as described by Jerry (or maybe a different one tailored to your circumstances), please log a case with your local customer support centre.

[Stephen Eickhoff_1]

Some of us are hobbyists and ineligible for support from HP. It so happens that I work for a company that provides OpenVMS-based solutions, but IMAP is not a product we sell or support so I felt it would be inappropriate to use our HP support resources to troubleshoot my hobbyist's issue. At least if I post issues like these in the forum, there's a chance someone at HP might accidentally see them. IMAP has been broken since 5.4 ECO 4, so OpenVMS engineering obviously is not aware.