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