Conference iosg::all-in-1

Hi Dan,

Just to clarify - you mean the SUBSCRIBERS: distribution list don't you? (The 
SUBSCRIBER DSAB is the DDS DSAB - nothing to do with mail delivery).

IMExtremelyHO, I'd say it shouldn't cost too much to add a few comment 
characters into the code!!

grahame

    Grahame,
    
    Yes, I ment the distribution list.  Will get in touch off-line.
    
    Thanks!
    dan

Who should Dan contact in IOSG to get an answer to this?

Cheers,

grahame

    I think this sort of thing is handled through the support team, so the
    customer should mail their credit card number to Debbie Hellmann@REO.
    
    Whether we'll actually want to do it at all, is another matter. The
    customer will need to understand that the 'fix' will probably
    get unfixed in the next version too.
    
    Since this is asked sufficiently often, I think a better plan is to
    make approaches to the Product Manager (Dave Holt@REO) and beg for this
    to be a standard option in the base product. Of course that's not
    likely to suceed either, since a) this is a change to the VT
    functionality, which we aren't doing much of, and b) we don't have any
    spare resource to do it.
    
    FWIW, I agree with Grahame that it would only need a couple of comment
    characters to make this change!

    re -.1
    
    > The customer will need to understand that the 'fix' will probably
    > get unfixed in the next version too.
    
    This is not an issue as the customer is migrating out of ALL-IN-1.
        
    > FWIW, I agree with Grahame that it would only need a couple of comment
    > characters to make this change!
    
    In that case I won't even bother Debbie.
    
    Thanks!
    Dan 
    

Trying to avoid sounding simplistic, but the quickest workaround could be to
create a secondary distribution list which holds the Autoforward addresses. 
This can be done easily and a batch file could update the DL as often as you
like.

This could be implemented straight away without the need for code changes. 
The customer then simply mails Subscibers: & Autoforwards: when he wants to
reach all mail boxes.

Regards,
Karl.
[Posted by WWW Notes gateway]

Bit of an aside:

.0: "design restriction"

It was actually an intentional design decision to do it that way, as that's
what made sense at the time.  It's only a restriction because they're trying
to make it do something it was intentionally built not to do.  It's a bit like
saying a speed limiter on a coach/lorry is a design restriction.

However the World moves on, and what was a sensible decision a few years ago
doesn't match what is needed today.  Out of interest, what is the mechanism in
Exchange for sending mail to everybody on a given server?  Maybe we shoul duse
that as our model.

Scott

    Re: .6
    
    > Trying to avoid sounding simplistic, but the quickest workaround could
    > be to create a secondary distribution
    
    Karl, the guy asked for a "simple solution" but never completed his 
    sentence when I gave him that option. Sounding simplistic is part of 
    my job!  :^)  He has 4500 users and no telling if ALL-IN-1 will be 
    happy with such a large number of records in one DL, not to mention 
    performance degradation.
    
    Dan (who_is_now_working_with_another_customer_who_swears_she_had_not
        customized_yet_mail_sent_to_SUBSCRIBERS:_has_gone_to_SMTP_address!!) 

    <<<< He has 4500 users and no telling if ALL-IN-1 will be happy with
    <<<< such a large number of records in one DL, not to mention 
    <<<< performance degradation.
    
    Try not to confuse ALL-IN-1 with some other mail systems that haven't
    discovered scalability yet. This is a trivially small DL.....
    
    Graham :-)

    Hi Graham!
    
    I guess I was recalling the old restriction and the following paragraph
    in the V3.1 Mail Management guide:
    
    	    When OA$MTI_LIMIT_LISTS is set to one, the default
            maximum number of addressees that can be used on a mail
            message is 550. It may be possible to increase this value.
    
    Ok, I can have him set the logical to 0 but what about performance?
    
    Thanks!
    Dan

    Yes, it *WAS* a restriction in *VERY* old versions (V2.3 or earlier?)
    but it hasn't been for a long time. Nowadays, people most often use that
    logical to prevent us blowing up PC based mail systems, most of which
    can't handle that sort of address list.
    
    Performance shouldn't be a problem (as long as every message doesn't
    have that sort of DL!) since I assume that a system of that size will
    be comfortably sized. If the users don't like the wait when sending the
    mesage, then using SECOND CLASS will probably help.

I seem to remember that OA$MTI_LIMIT_LISTS was introduced in V2.3, and was 
intended to prevent long distribution lists being sent to pre-V2.3 systems.

Re performance - are you certain that using a distribution list of 4500 people 
will perform worse than using SUBSCRIBERS: to send to 4500 people?

grahame

> I seem to remember that OA$MTI_LIMIT_LISTS was introduced in V2.3, and was 
> intended to prevent long distribution lists being sent to pre-V2.3 systems.

    Oh, yes! Remember co-existence installations? That is when we mostly
    saw the problem!
    
> are you certain that using a distribution list of 4500 people 
> will perform worse than using SUBSCRIBERS: to send to 4500 people?

    No, Grahame, I cannot be certain (I have not tested it and I do not
    know anyone who has - may be I should call whomever is sending 
    Bob Palmer's X-mas messages!) but I would have to raise a flag since 
    when we deal with DLs we are dealing with sequential files and the 
    customer uses DLs as if they are PAs.  If he goes with DLs then 
    "secondary" mail, as Graham suggested, is the way to go.
    
    Warm regards!
    dan
      

    I agree with the supplemental list being the easiest solution, if
    you want to do a little extra coding to avoid reeducating the users you
    could have ALL-IN-1 automatically enter the auto-forwards list to any
    message that contains subscribers:  You could do it either by adding a
    few lines to (I think special.com) or by adding a /post to the emhead
    form.

    ANother solution along the same lines
    
    SUBSCRIBERS: is not an acutal distribution list.
    
    You could create a system distribution lists called SUBSCRIBERS:
    which contained
    
    SYSTEM DISTRIBUTION LIST				(AUTOFORWARD:)
    ALL USERS ON THIS NODE				(SUBSCRIBERS:)
    
    If a user types SUBSCRIBERS: it is the d'list that will come up.
    
    This solution works because of the search order used in EMHEAD.
    
    Not the cleanest solution, but the simplest by far.

    Re: .15
    
        Yes, the DL called SUBSCRIBERS: gets selected when creating
    the msg. but, in the end, mail fails to deliver when you "send" 
    (it uses MAIDES=MAIL-LIST field of SUBSCRIBERS: PROFIL record as if
    it is a command procedure and tries to execute MAIL-LIST.COM).
    
    Am I missing something?
    
    dan

    
    	When you add subscribers: to the subscribers dlist, make sure you
    add the one that says ALL ALL-IN-1 users on this node.
    
    When in the DList type SUB {gold L} you should see both the dlist, and
    the true subcribers function.  Make sure you pick the right one.

    I have done this until my head spun!  Have you tested it on V3.2?
    
    Dan

I don't think this will work on *any* version of ALL-IN-1, for the reasons Dan
explains in .16.

Scott

    no, because I originally developed it as a way of preventing users from
    using subscribers, before that facitilty was available.  I created a
    dummy emtpy subscribers lists which superceded the subscribers
    function.
    
    I guess my other solution is the cleaner: add a /POST function to the
    EMC form, if subrscribers is one of the addresses, add AUTO-FORWARDS

[Posted by WWW Notes gateway]

Hi,

I worked on a site with 8500 profiles on All-IN-1 and just under 100,000
addresses company wide.

They started rolling out MS-Mail and quickly we ran into trouble with large
DL's.

If I remember correctly, MS-Mail was restricted to DL's of a maximum of 250
addresses.  If it exceeded that then the MS postoffice bounced the mail back.
ONE MAIL PER ADDRESS !!!  Very soon we had disks filling up all over the place
and heavy mail traffic due to mail errors.

Point is, if you have another mail system within the company - find out its
restriction and split the DL into smaller multiple DL's if need be.

Yes, we used SECOND class for the subscriber mails AND we restricted who could
send to this address.  The Sender will be busy for quite a few minutes so its
best delayed.

Regards,
Karl.
Reading CCS.
[Posted by WWW Notes gateway]

    Re .-1
    
    Yes, as was discussed in .13, we introduced the limit on DLs to protect
    other "mail" systems, rather than because we couldn't cope!