Conference iosg::all-in-1_v30

2676.0. "DDS and Housekeeping Procedures" by GALLOP::SWINEY::John-M (To Live and Die in Goole !!!) Fri May 07 1993 10:23

    Hi,

    A customer has recently started running the ALL-IN-1 Mail Janitor assett 
    under V3.0.  Problems have arisen because the system is configured to use 
    DDS as its primary directory (OA$DDS_PRIME=2).  Two problems occur which I
    will detail here because they potentially/do affect all other housekeeping
    procedures.

    With MJU, a mail is sent to the users if any mail is moved to their 
    WASTEBASKET, indicating this fact and offering them the chance to refile
    it. It appears that this mail is sent using 

    MAIL TO "USER"
 
    which follows the validation imposed by OA$MAIL_ADD_ADDR (??).

    Consider the following;

    "Secondly, it appears that Mail Janitor obeys the setting of OA$DDS_PRIME 
    logical (ours is set to a value of 2). I say this as we have had the case 
    that an account that was processed by Mail Janitor with the name LOWEN  for
    NEIL LOWE. It should have had a mail sent to it indicating messages 
    deleted. Mail Janitor appears to have looked up the user in DDS. In this 
    case it has found a match on surname for the user EILEEN LOWEN instead of 
    NEIL LOWE whose account was processed. The mail has subsequently been 
    delivered to the wrong account."

    The second problem not only affects MJU but also all other housekeeping 
    procedures.  If the (DDS) lookup finds more than a unique match (multiple
    surnames), it goes into form EMSADD and hangs.  The housekeeping procedure
    goes no further.  As most sites nominate MANAGER as the account to receive
    reports, it will always be a problem.

    Two questions;

    - Why do housekeping procedures not disable DDS lookup as they are only 
    relevant to local systems.

    - How do I do this for myself (define OA$DDS_PRIME = 0 at the top of
    SMJACKET.COM ?)

    Regards, John

    I have set the previouse note hidden because it contains an implied
    committment that specified functionality will be included in a possible
    future release of ALL-IN-1 when no such release of ALL-IN-1 has been
    publicly announced to my knowledge.
    
    If the author wishes to remove the relevant line then all will be fine
    though I think he should be posting this note in the European ASSETS
    conference anyway.
    
    Regards,
    
    Andrew.D.Wicks
                        

    I have removed the offending line from .0. Although the question about
    MJU should, as .1 observes, be asked of the ASSETS support group, I
    will address (if you'll excuse the pun!) the general concern.
    
    This is a known problem, previously showing up as mail reports being
    sent to the wrong "MANAGER" in networked systems, since all the
    MANAGERs get DDS entries, and on DDS prime systems, the wrong one was
    often chosen. I hadn't heard of the symptom you describe before.
    
    This has been overcome in at least one of the housekeeping procedures
    with a /JOB (I think) logical definition of OA$DDS_PRIME to 0. Since
    I'm at home, I can't find it, but I'm sure you could find the place we
    do it already with a few searches and emulate the fix wherever else is
    necessary.
    
    If you know of any other places where this is still a problem in the
    shipping version of the product, please SPR them, so they can get
    looked at for a PFR.
    
    Thanks, Graham

    I'm now back in the office, and see there's already a /PROCESS
    definition of OA$DDS_PRIME in SMJACKET, and several similar ones in
    other SM command procedures. So as I said before, please let us know of
    any other places (apart from MJU :-) ) where this is still a problem.
    
    Graham