Conference iosg::all-in-1_v30

1889.0. "ACCVIOs when replying to NO MAIL accounts" by GIDDAY::LEH () Thu Dec 03 1992 06:06

ALL-IN-1 IOS 3.0 running under VMS V5.5-1

A(nswer) mail message to user with NO MAIL flag set in profile results in 
ACCVIO with stack & register dump, i.e. account TEST1 having MAIDES field as NO 
MAIL sent mail to account TEST2, who then replied and ACCVIO occurred. This 
doesn't happen to ALLIN1 account.

%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=20202020,
PC=001A2264, PSL=03C00000

  Improperly handled condition, image exit forced.
        Signal arguments              Stack contents

        Number = 00000005                00000000
        Name   = 0000000C                201C0000
                 00000001                7FF08470
                 20202020                7FF08438
                 001A7464                001A68B4
                 03C00000                00000001
                                         0006DD0C
                                         007F6D20
                                         00000001
                                         7FF0842C

        Register dump

        R0 = 0000000C  R1 = 7FF08430  R2 = 7FF0842C  R3 = FFFFFFFF
        R4 = 00073418  R5 = 007F66D0  R6 = 00000096  R7 = 00000020
        R8 = 00000004  R9 = 001A7741  R10= 001A7416  R11= 00000000
        AP = 7FF083AC  FP = 7FF0836C  SP = 7FF083E8  PC = 001A7464
        PSL= 03C00000

This ACCVIO was also written in OA$MTI_ERR with no other details.

Also, account TEST1 sent mail to itself supplying ME at TO field also resulted 
in same dump. Using I at TO field worked fine

My SET WATCH trace on end-user accounts showed at the very end, access to 
[ALLIN1.MGR] was made when ACCVIO occurred. Relaxing protection flag W:RWE on 
this directory, for testing purposes, didn't make any differences.

A1TRACE showed it occured when trying to release record locks on CAB$SHAR_E 
after having updated relevant filecabs: deleting PDAF record in [.MSG], 
copying it to SDAF, deleting CREATED record in DOCDB and adding SENT record 
to DOCDB.

Have had this problem escalated but still interested in any workaround or code 
fix

Thanks

Hong 
CSC Sydney

    Hong,
    
    how privileged (in VMS terms) are the accounts since i've just tried
    this and can't reproduce it (TMPMBX and NETMBX on both accounts I think)
    and I got a friendly non-delivery message from the POSTMASTER
    telling me that           - user cannot accept new mail;
    
    regards,
    
    Andrew.D.Wicks
                                                                    

    Hi Andrew
    
    Both sending and receiving/replying accounts were having default process 
    priv: TMPM and NETM and default process rights: INTERACTIVE and REMOTE
    
    Today I tried putting on all privs and ALL-IN-1 rights such as
    OA$MANAGER, OA$ADMIN to receiving/replying account but ACCVIO still
    occurred. 
    
    Another test was to include another recipient with MAIDES different
    than NO MAIL when sending e.g.
    
    TEST1 (having NO MAIL in MAIDES) sent to TEST2 and TEST3 (both having
    ALL-IN-1 in MAIDES)
    
    TEST2 replied to both TEST1 and TEST3 ----> OK
    TEST2 replied to sender only, TEST1   ----> ACCVIO
    
    again full privs and rights were given to TEST2
    
    BTW, Reading confirmed this problem was reproducible
    
    Hong
    

    ALL-IN-1 Support are currently investigating this problem. In the
    meantime the following may clear up the confusion on priv'd and
    non-priv'd accounts.

    The ACCVIO only occurs if the account sending mail to an account
    with "NO MAIL" set has *not* got ALL-IN-1 profile priv - "SUBSCR".

    If the account has the SUBSCR profile priv set then the ACCVIO will not
    happen.

    This is why it is not reproducible with ALL-IN-1 priv'd accounts and
    any other account that happens to have that priv set.

    Cheers,
    Russell Elliott (ALL-IN-1 Support)