Conference iosg::all-in-1_v30

    
    I know that you said that you were not doing backups when this
    occurred, but I also found this article in STARS and thought that
    maybe it would help shed some light on the cause of the problem.
    Sounds like this will occur when ALL-IN-1 is initialized (by any
    process) and this file cannot be opened for any reason.  
    
    Good luck,
    Faith donohue
    
    *****************************************************************
New Version of MRPASSWRD File Is Created; Password No Longer Valid


COPYRIGHT (c) 1991, 1992 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.


PRODUCT: ALL-IN-1 V2.3, V2.4

SOURCE: Customer Support Center/Atlanta USA

\by Bina Cline (152938) - OA3309
\SRF, A$AL230587, THR-13172 also ICA-29535, THR-13216

PROBLEM:

When incremental backups are run on the system at night if the sender
runs, it creates a new MRPASSWRD.DAT file containing the default
password (A1MBX). Since this is not the correct password which
has been set on the system (in Message Router) it causes the ALL-IN-1
sender and/or fetcher procedure(s) to fail.


CAUSE:
                                 
If the MRPASSWRD.DAT file in OA$DATA (which contains the Message 
Router password for the ALLIN1 mailbox) is locked for any reason, 
then when any user logs into ALL-IN-1, their attempt to access this 
file fails and causes a new version of the file to be created with
the default (A1MBX) password.

The problem is caused by the Mail Initialization Routine, which opens
OA$DATA_SHARE in UPDATE mode.  This operation fails if the file is locked
and forces another MRPASSWRD.DAT to be created with the default password.

SOLUTION:

The problem you describe is a restriction in versions V2.3 and
V2.4 of ALL-IN-1.  However, it is resolved in the next release 
of the product, ALL-IN-1 IOS V3.0.
\********************* FOR INTERNAL EYES ONLY ************************
\*
\* A solution for this problem has been ICO'd for Diamond (1255)
\*
\********************* FOR INTERNAL EYES ONLY ************************

We strongly recommend that ALL-IN-1 is shutdown prior to the running
of backups; failure to do so may result in corrupt SDAF files.

However, we suggest the following alternative may be used to overcome 
this problem:

In the BACKUP command line, the qualifier:

      '/EXCLUDE=OA$DATA_SHARE:MRPASSWRD.DAT'

may be added. Obviously, a separate backup of this file may be
necessary. To accomplish this, the following steps may be taken:

    1. Hold the Sender and Fetcher (from a batch job).
    2. BACKUP/SELECT=OA$DATA_SHARE:MRPASSWRD.DAT
    3. Start the Sender and Fetcher.

    Any more ideas what might lock this file please ??
    
    Thanks
    
    Clive

    OK, what else needs to write and lock the file other than the ALLIN1 
    manager to do a CMP? 
    Shall I just grant the ALL-IN-1 Manager an identifier and put an ACL on 
    the file to prevent everyone except ALLIN1 writing to it ? 
    A security ACL creates too big a log file file which is a problem for the 
    customer.
    Maybe I could just remove all write protection from the file and switch 
    privs on when required, or would this stop other processes writing that
    need to ?
    
    Thanks
    
    Clive

Hi Clive,

Sorry you haven't had a better response to this so far. It would seem to me 
that you'd be OK to go ahead by preventing write access to all but ALLIN1 - as 
you say only the CMP option should be locking the file.

You say you had accounting turned on - did that show any evidence of anyone 
else trying to write to it?

I'd give it a go - and if you still get new files created, raise a bug.

grahame

    Re .3
    
    I'd be surprised if many things *write* to this file, and hence I don't
    see how a:
    
    	SET FILE/ACL=(ALARM_JOURNAL=SECURITY,ACCESS=WRITE+SUCESS+FAILURE)
    
    or whatever the syntax is exactly, would cause a very big log file.
    
    Graham

    Thanks chaps,
    
    re .5
    
    I haven't had any response from the log yet but I think you'll find
    that 'WRITE' actually means READ too - thus it's quite big!
    
    Thanks
    
    Clive

    No more problems detected since the customer raised the version number
    on the file to 32767 to prevent a new one being created.
    
    Clive