The package feature took about 45 minutes to write, including testing time. It wasn't really difficult at all. I am therefore certain that the NIC *could* add it into NICSERVE in less than one month ( ;-) ) if they really *wanted* it, the point is they never intended to provide it (what would they offer? QUESXX PACKAGE? JUSTIFY NICPKG? :-) ). But then what can you expect from people who need 3 weeks to do a DIRM ADD and a CARD LOAD, one week to set up a dummy list with two userids in it, and test the thing at the *incredible* rate of one test mailfile a day? (gosh, that's really a hard day's work ;-) ) Ooops, I realize this is not the 1789-L list. Never mind :-) Anyway, I have decided to implement packages this way: 1) You make all the files available on the server, along with a file called "packagename $PACKAGE". This file lists all the files which belong to the package, and ought to list itself (so that the recipient can check which files are missing and which are there). It can also contain comments. 2) The $PACKAGE file is just a normal file, which you can GET and PUT the nor- mal way. Its GET code should be set according to the GET codes of the files in the package -- see below. 3) When you do a GET xxxx PACKAGE, the GET code of the $PACKAGE file is checked and if it turns out you are allowed to get the package, LISTSERV starts sending the individual files one after the other. The GET code of each individual file is still checked, though. If a file is missing (not yet available or suchlike), it is skipped. 4) You can't PUT a PACKAGE. You must issue a PUT for each individual file, of course. 5) If you AFD/FUI to a package, you get an AFD/FUI anytime one of the file is updated. You do not get AFD/FUI for the whole package but just for the files which have been updated. You can try GET CHAT PACKAGE on my server, but please note that it WILL send you all the files... except the (huge) helpfiles which I purposefully did not make available yet :-) You can GET CHAT $PACKAGE if you just want to see what the definition file looks like. The Netserv cache-disk is working fine in test mode here. We'll see... It is implemented by means of a user-tailorable exit being called when a PUT command is received for an unknown file, and there will soon be a similar exit for GET. Eric