On Fri, 14 Jul 1995 09:12:49 EDT Ben Chi <[log in to unmask]> said:
 
>Just yesterday, in response to a user saying that his ISP was clobbering
>his digests  by chopping them into  little pieces and sending  them on a
>bite at a time, I set his  options to NODIGEST (I thought). This morning
>I queried his options and found DIGEST to be set. Did he reset it? Or is
>Alzheimer's setting in? With 1AAACACx0+ there's no way (for me) to tell.
 
I'm sorry but I don't see how "am  R 94221 AA" would help in that matter.
If QUERY says DIGEST is set then  DIGEST is set. It uses the same routine
to get this info as the rest of the code that needs to know if the option
is set (unlike  the previous method where each routine  was free to check
position X  for value  Y and where  inconsistencies were  possible). It's
true  that you  can't visually  check  that the  bit  is set  but in  all
likelihood with "am R 94221 AA" you would note that the bit is indeed set
as claimed, and would  be back to the original question -  how did it get
set? You would have to search the logs to see if the user or owner issued
any SET command.
 
>Can LSoft provide us list managers with  a magic decoder ring so that we
>can  translate these  codes  into usable  information? I'm  particularly
>interested in LastDateModified, which QUERY <list> for <subscriber> does
>not reveal.
 
All the information except for this field is displayed by QUERY. The last
activity field  is set on  a lot of  occasions, including posting  to the
list. I know that  many list owners have been using  it as a subscription
date field and complained vehemently  about its encoding. However, it has
never  been a  subscription  date field,  it's a  field  used to  monitor
renewal  requests and  it  contains  either a  last  activity  date or  a
scheduled deletion date. If someone can  make a case for having access to
its field for what it *actually* represents,  I will add an option to the
QUERY command to display it.
 
  Eric