Conference iosg::all-in-1_v30

    Hi,
    
    Have you checked the MAIDES field in the PROFIL of those people who
    claim not to have recieved the mail?
    
    Anybody who has a MAIDES field that isn't ALL-IN-1 will not recieve
    mail that's sent to SUBSCRIBERS:
    
    Neil
    ~~~~

    No... the "Mail Destination" fields are OK. I received mail addressed to
    all subscribers from another authorised user earlier in the day without any
    problem so it can't be that.

    Thanks, any more places I can check ?

There is a profile field RCV$SUB.  This must be 1 for the user to *receive* mail
sent to SUBSCRIBERS: (as opposed to PRVSUB which allows a user to *send* mail to
SUBSCRIBERS:).

There is no UI to support this field (the reasons why have been amply discussed
before), but the manager can get at it on form PROFIL (specifically, the fifth
continuation screen).  Check that it's set to 'Y'.

Re. 2: sorry, I don't understand the logic of your answer.  Just because you
received mail sent to SUBSCRIBERS:, how does that mean that the problem can't
be with MAIDES values of *other* users?

To add to what Neil said, only those users whose MAIDES value are ALL-IN-1 or
ALLIN1 will receive mail sent to SUBSCRIBERS:.

Another thought: this is an English (or British :-) system?  There is a known
problem, due to a translation error, with MAIDES on French Canadian systems...

HTH
Scott

� Just because you received mail sent to SUBSCRIBERS:, how does that mean that
� the problem can't be with MAIDES values of *other* users?

    Ok...sorry for my poor answer. I, as system manager, created 100% of the
    accounts and, while one cannot be 100% sure, I'm reasonably confident that
    the MAIDES fields are correctly set (by and large). Earlier in the day, I
    had received a number of mails (addressed to all subscribers) from one
    authorised individual. Later in the day, another authorised individual sent
    mail to all subscribers which I, and apparently a number of other people,
    did not receive. The characteristics of MY account did not change in the
    meantime.

    Now... while I cannot be certain that there was not a problem with the
    earlier mails and I was just one of the lucky recipients, I KNOW there was
    a problem with the later mails because I have seen the sender's outbox
    and I KNOW I didn't receive the mail.

    I've checked in case she had created her own distribution list called 
    SUBSCRIBERS: (or some such) but nothing is apparent. The failed mail was
    sent at 5:30pm (ish) so it's unlikely to be a housekeeping job interfering
    but I am lost for ideas. I've asked other fellow system managers and they 
    have never heard anything like it either. The disks appear not to but full,
    quotas seem OK, nothing has "fallen over" 

    This is, by the way, an English system (or shall we say British ?).

    Totally bemused.

The second mail sent to "all subscribers" that you did not receive: what exactly
is the address in the header (as seen when reading it from the sender's outbox)?

Is it "All ALL-IN-1 users on this node     ( SUBSCRIBERS: )", or is it a list
of addressees?  Does the message look the same or any different when read from
one of the recipient's (who did receive it! :-) accounts?  Do "SH" (Show Header)
and see which shared directory the message is in (check that both sender and
recipient point to the same file).  Is the disk containing this directory full,
or near full?  Is the disk containing the DAF for that mail area full?

Scott

    RE .3
    
    RCV$SUB was only added in V3.0, whilst .0 has V2.4.
    
    Also people who have their mail AutoForwarded don't get SUBSCRIBERS:
    mail.
    
    The CORE customisation does some stuff with SUBSCRIBERS, do they have a
    support conference in which you could ask?
    
    Graham

re .5

� what exactly is the address in the header... ?

TO:  All ALL-IN-1 users on this node      ( SUBSCRIBERS: )

� Does the message look the same...?

TO:  All ALL-IN-1 users on this node      ( SUBSCRIBERS: )

� Do "SH"... ...check that both sender and recipient point to the same file)

    Yes... it's the same file and both machines (that handle ALL-IN-1 in the 
    cluster) can see it. The directory it's in isn't new (500+ files) and 
    neither that disk or the disk with the DAF file are even remotely full.

    Can I check the reference count for that file and see how many people DID
    receive it ? Maybe that might give us a clue ?

Re .6

    The core stuff isn't new. It's been flying fine for quite some time now (like
    6 months and more). 

    Thinking... what and where handles the sending of such a mail ? If the user
    were to kill her job (logged in over LAT from PC) before some time interval,
    could it effect the sending of the mail ? I don't know if this even possibly
    happened but it's a thought I suppose.

Thanks,
Ross

Hi,

>> If the user were to kill her job

That was my next suggestion... if the user sends the mail FIRST_CLASS or
EXPRESS, it gets sent immediately, in the user's process, to all the users.
If the user gets fed up with the delay and hits CTRL-Y (or gets kicked off the
system for other reasons, such as network faults), and their process dies, the
send won't complete.  You can see if this is the case by finding out which
users didn't get it... if all users up to some point in the profile (taking all
the usernames alphabetically) got the message, then the rest didn't, this
points to the send operation aborting part-way through.

Scott

    Hmmm... I just sent a mail to SUBSCRIBERS and, after 15% of users having
    so far replied, it would appear that up to "Mc..." received the mail and
    after that no-one did. Those who claimed they did I spoke to personally
    and they later confirmed they didn't.  :-|

    So... it would appear at a cursory glance that beyond a certain point in
    the profile, no-one received the mail. I suspect operator intervention at
    this point.

    Thanks for your help so far, I'll post a reply when I get more 'evidence'

Ross

    Ross,

    My feeble recollection was that there was a bug in ALL-IN-1 which would
    cause this sort of behaviour if a user's record in PENDING.DAT was
    corrupt.

    You might want to take a peek or two at OA$DATA:PENDING.DAT.  The first
    thing to do would be:

    $ ANAL/RMS OA$DATA:PENDING.DAT

    The next thing that you might want to do would be to search for the
    message that was just sent to SUBSCRIBERS:.  Look for the filename
    which you can get from OA$CURDOC_FILENAME right after doing the send of
    the message:

    $ SEARCH OA$DATA:PENDING.DAT OA$SHARn999:zname.WPL

    where OA$SHARn999:zname.WPL is the file name you received from the
    OA$CURDOC_FILENAME symbol, of course.

    You might want to do:

    $ DUMP/REC DISK$A1:[ALLIN1.DATA_SHARE]PENDING.DAT/OUT=PENDING_DUMP.TMP

    immediately after doing the send and then use your favorite editor to
    search for the file name.  This would point you to the exact stopping
    point.

    Good luck,
    don