Phase 1a of the file server functions has been written and tested. This includes the ability to create catalogs (similar to the VM FILELISTs) and to organize files in a hierarchical manner, so that you can have a file called /abc/def/ghi/my.file, although during phase 1 this will not necessarily be very user friendly for the person maintaining the files and directories. Phase 1b is AFD/FUI and a few other minor changes, and is under development. The plan is to release phase 1 (1a + 1b) together with version 1.8c. This should, for most sites, provide a similar level of functionality as the VM file server functions, with a simpler interface (just like, say, the management of WELCOME files is easier in the non-VM versions). Phase 2 will contain further improvements that will, to a large extent, be based on customer feedback following the release of phase 1. In other words, the design for phase 1 was fairly straightforward based on what people had been used to since 1987 and on the code we already had. I expect that people will be able to migrate from FILELISTs to phase 1 CATALOG files in about 5 minutes, and I don't expect anyone to have any major complaint, other than "This should be easier to do, although now that you mention it, it wasn't easy on VM either". For phase 2 we have all sorts of ideas, but it's not clear what people will need first. The database functions are a hot potato because what the majority of our customers are clamouring for is graphical, web-based database access. We have reached a point where some customers will actually get very upset if we release a text-based database engine, unless a web-based database feature is also provided at the same time. Conversely many long-time VM customers have indicated that, to a large extent, web-based database functions would be an acceptable substitute, although there's always a list or two where this isn't workable. We try to make all customers happy, but this isn't always possible. The file server functions got done first because there were a lot more people asking for them, and because they aren't controversial. Now, version 1.8c will also include full support for the INDEX subscription option (already written and tested). This includes a new command that allows you to retrieve individual messages from the archives (this command is used internally by the INDEX code, but will be documented as NDSU's experience with /SHIP makes it clear that this is something power users do find useful). I imagine that we could implement a SEARCH command that would look for certain words or phrases in list archives, and return item numbers that can be used to retrieve the postings in question. Something similar to SCAN, with a simpler syntax than the database functions. This might provide some relief for sites that use the database functions for simple things, and it should hopefully not alienate the graphical-oriented customers because it is a minor development that nobody will dream of labeling a "strategic direction" or anything like that. Comments? Finally, the main reason we're late for all these developments is that we don't have enough manpower. We keep hiring people, but we keep not having enough manpower anyway. We've hired three people in December, one in February and one this month. Two more are about to be hired, realistically they'll sign in April. The three we've hired in December are already overwhelmed, and in a few weeks they're going to have three new people to train. As the sales folks say, "this is a nice problem to have", but it's a problem nonetheless. I'm not trying to whine here, but I'd like to clarify, since it isn't intuitive or obvious, that just because there are a bunch of qualified list owners out there doesn't mean that we can hire more support people at the snap of a finger. The list owners in question have a job as teachers, scientists, journalists, etc. Most of them simply do not want a career change; they think they're already spending too much time working on a computer and away from their field to keep their list together as it is :-) I'll trade you 50 junior programmer resumes for one seasoned list owner or LISTSERV admin :-) Eric