Bill, I realize *you* know all that, but not every list owner has been running a large system for 10 years, so here goes... When people are paying you for new versions of a software product and you tell them that capability X is present, you need a Damn Good Reason to remove this capability in a future version. It had better be something old that can be argued to have become obsolete. Even so, many people will complain. This is why one has to be careful when declaring that something is supported. If as a customer you have a need to do something that currently can only be done through unsupported methods, you should state your requirement so that we may consider the provision of a documented interface in a future version. In most cases these documented interfaces are in fact more convenient for the customer than the unsupported method. In some cases they are less convenient, but at least you don't have to worry about them disappearing in the next version. From L-Soft's perspective, the format LISTSERV uses to store lists on disk is none of the list owner's business. L-Soft needs to be able to change it to add new functionality, remove limitations or improve performance. The GET command returns a list of subscribers with various flags in a format that is suitable for (1) saving as a backup on one's disk, (2) exporting/transferring the list to another LISTSERV host running the same version (or a more recent version) and (3) getting a "super-REVIEW" listing of all the people on the list, including the ones that are concealed. The use of the flag columns is not supported. Because it is not supported, we were able to add the new REVIEW/EDITOR/NOPOST options without making a major change to the list format that would have made people even less happy. Similarly, because editing the LIST files directly off LISTSERV's disk is not a supported operation, we were able to significantly improve the performance of LISTSERV with large lists by caching all sorts of additional data. If we had guaranteed that lists can be edited directly, we would have been stuck. However, if you have a need for a list of currently available options in a compact, easy to parse format, this can and should be provided through a standard command. I did know that people used the flag codes, but I thought (based on the discussions on this list when flag codes were mentioned) that this was done only to do the equivalent of QUERY WITH. I did not know that some people used it to prepare statistics. Anyway, I'll look into providing a standard method for that in the next version. Eric