On Fri, 6 Jan 1995, Eric Thomas wrote: > 1. Joe gets list header, planning to change option A. > 2. File takes a while to reach Joe. > 3. Meanwhile Jack gets list header, planning to change option B. > 4. File reaches Jack quickly. Jack updates the list, option B is set. > 5. File finally reaches Joe. Joe sets option A and sends the file back, > undoing option B. > 6. The next morning, Jack sees that LISTSERV removed option B without > reason or warning, checks his mailbox just to be sure, and reports the > bug :-) The easy way to get around this, given that remote listowners may have to wait a long time for the output of their "jobs" is, if you have multiple listowners, one, and only one, of the owners is in charge of making changes to the header, filelist, etc. The others *can* do it, but don't, they ask the person whose job it is to do it. That way you don't have owners working at cross purposes and you can always use nolock. And keep a copy of the current header, filelist, whatever hanging around so you don't have to wait, just make the changes and send it in. I have the same problem with UBVM as Natalie has with UGA. I have had to wait 12 or more hours for output. It's a major node, lots of local users, lots of lists, lots of stuff routed through it, etc. and things can become veerrry slooooow at times. I try to do time consuming things early in the morning or late at night. One of the things remote owners have to put up with. If I need a really quick answer for things like query, scan etc. I will tn3270 to our error account. Since it is at UBVM I get the answer very quickly (local users get priority). Don't make header, filelist changes that way as I am a total duffer on VM and don't trust myself to get it right. If you are a remote listowner you might ask the host site for a courtesy account for that sort of thing. Douglas Winship Austin, Texas [log in to unmask] Secondary AUTOCAT Listowner