On 01/16/2003 09:37:14 AM [log in to unmask] wrote: >GLOBAL_LIST_EXCHANGE = 1 in LOCAL SYSVARS. I mean, that's the setting you don't >want (change it to 0). Ah, ok. I must have zoned out earlier when I was searching for it because it was there, plain as day. With a long paragraph explaining. D'oh! >> Looks like I'm missing one update. 1.2d is the latest? >Yes. Ok, we have now entered the new millennium :-) >> It definitely went to the right service machine, LISTTEST. > >Darn! Do I get a second chance? :-) You can have as many chances as you like. >My guess this time is that the list is not >actually called TEST, but let's say XYZ. You have XYZ LIST A1 with "List-ID= >TEST" or something along these lines. You may even have the list set up so that >the published name is TEST, but its canonical name is XYZ. I've tripped myself up a few times with the list name vs. list ID thing. Output of "lists" command: * LSTAFF-L -LISTSERV Maintenance Staff * TEST -List for testing MAILER * Alias: LSTESTLS * * (-) Lists marked with a minus sign only support RFC822 mail. I've used list IDs for all my lists because of the 8 character limitation on names in VM. The list name corresponds to the VM userid and the list ID corresponds to what the owner actually wants to call the list. I've mixed these two values up more than once. Here, the list name (i.e. the VM file name) is LSTESTLS. The list ID is "test" and that's the address to which I'm sending mail. That works fine when the VM userid is in place and LMail is not (I had the alias defined in my SMTP NAMES file so the mail would get to the right userid). I tried sending to lstestls also, same result. <digress> I also tried sending to LSTAFF-L, same thing but no SET LIST option so I got the other response. Strangeness when I tried to do a SET LIST: tell mailer for lstaff-l set list Ready; T=0.01/0.01 10:26:48 * Unknown user preference option - "CLASS= ". Try HELP PREFERENCES for a list * of valid names. tell mailer for lstaff-l set list Ready; T=0.01/0.01 10:28:14 * The LIST and NOMAIL attributes may only be set by the LMail administrator * using the FOR option. tell mailer for lstaff-l set list Ready; T=0.01/0.01 10:28:17 * The LIST and NOMAIL attributes may only be set by the LMail administrator * using the FOR option. tell mailer for test set list Ready; T=0.01/0.01 10:28:22 * User preferences for TEST successfully updated. MAILER console: 16 Jan 2003 10:26:48 From MAINT@MSACVM: for lstaff-l set list 16 Jan 2003 10:26:48 From LSTAFF-L@MSACVM: set list CLASS= 16 Jan 2003 10:26:48 To LSTAFF-L@MSACVM: Unknown user preference option - "CLA SS= ". Try HELP PREFERENCES for a list (...) 16 Jan 2003 10:26:48 To MAINT@MSACVM: Unknown user preference option - "CLASS= ". Try HELP PREFERENCES for a list (...) 16 Jan 2003 10:28:14 From MAINT@MSACVM: for lstaff-l set list 16 Jan 2003 10:28:14 From LSTAFF-L@MSACVM: set list 16 Jan 2003 10:28:14 To LSTAFF-L@MSACVM: The LIST and NOMAIL attributes may on ly be set by the LMail administrator (...) 16 Jan 2003 10:28:14 To MAINT@MSACVM: The LIST and NOMAIL attributes may only be set by the LMail administrator (...) 16 Jan 2003 10:28:17 From MAINT@MSACVM: for lstaff-l set list 16 Jan 2003 10:28:17 From LSTAFF-L@MSACVM: set list 16 Jan 2003 10:28:18 To LSTAFF-L@MSACVM: The LIST and NOMAIL attributes may on ly be set by the LMail administrator (...) 16 Jan 2003 10:28:18 To MAINT@MSACVM: The LIST and NOMAIL attributes may only be set by the LMail administrator (...) 16 Jan 2003 10:28:22 From MAINT@MSACVM: for test set list 16 Jan 2003 10:28:22 From TEST@MSACVM: set list 16 Jan 2003 10:28:22 To TEST@MSACVM: User preferences for TEST successfully up dated. 16 Jan 2003 10:28:22 To MAINT@MSACVM: User preferences for TEST successfully u pdated. There are no VM userids called test or lstaff-l. Apparently, LMail thinks lstaff-l is special and tries to add a CLASS parm. I don't know why MAINT isn't an admin when acting for lstaff-l but is an admin when acting for test. I'm not terribly concerned about this one, for now. </digress> Ok, I blew away the original test list and recreated with list-id the same as the list name. Now LISTTEST recognizes the list but delays the mail for 10 minutes because MAILER (?) isn't a subscriber. MAINT actually sent the mail and is subscribed. So, two problems remain...sending to lists with aliases and preventing the delay. The first is the most important. We're migrating from a Windows product and I have lots of lists with long names. lisa