I have implemented the following prologtext variables to solve the problem of AFDs to generic fileids when the actual filename and filetype must appear in the prologtext: &FN -- actual filename &FT -- actual filetype &FL -- actual filelist in which the file is defined. You can also use &FILELIST. I don't see any use for this variable at present but it seemed more logical to implement it -- it's only one more line of code anyway so who cares... :-) &RECFM -- record format of the file. You could reasonably expect it to be always the same for a given generic fileid, but since nothing prevents the file owner to set different RECFMs for each file... &LRECL -- file lrecl, meaningless unless &RECFM = F. Suppressed blurb same as above... &= -- the value of this special symbol is "=". It makes it possible to place a keyword in the prologtext without having it interpreted by the command supervisor during the execution of the AFD command (a restriction of LISTSERV that can be overriden by dirty methods such as placing two copies of the keyword in the command -- the supervisor will only 'eat' one -- but I preferred to provide a clean way out...) Example: PW&= &DATE -- date of the file from the filelist entry -- yy/mm/dd &TIME -- as above, hh:mm:ss, *with* leading zeroes The last two variables were not part of Peter's requirement but I thought they might be VERY useful to ensure that old files do not override more recent ones just because they happen to be larger and are received AFTER the newest file... All the server has to do is compare the date from the prologtext with the date of the version of the file it presently has on its disk, and discard the file if it appears to be older. The actual implementation of the variables is very simple: you just place the desired symbols in your prologtext where you need them and they are substituted at execution time. A blank is required after the variable but not before. Example: AFD ADD * BLURB FUN PUT &FN &FT FUN PW&= SECRET "TSTAMP=&DATE &TIME " --> PUT FIRST BLURB FUN PW= SECRET "TSTAMP=87/03/08 12:43:25 " That's something a LISTSERV could process quite nicely, given a File Access Validation exec that checks the date/time stamp and possibly rejects the PUT. I have also modified LISTSERV to process AFD and FUI for deleted files too. This works as follows: - FUI: If the filelist entry still exist (ie the file was not part of a generic fileid), the new entry is sent back as usual, with periods in the appropriate fields. Otherwise a comment is placed in the FUI notification saying that the entry for the file has disappeared. This is not supposed to be parsed by a program but read by a human person. - AFD: If you have a non-empty prologtext, you get a copy of the file with just the prologtext and no data. You're then supposed to delete the file. If you don't have a prologtext, you get a dummy 1-record file saying that the file has been deleted from the filelist. Again, this is not supposed to be parsed by a program -- programs ought to use a prologtext, un point c'est tout. Finally, I am not too keen on the JCLPROLOG/JCLEPILOG stuff. Not that it's THAT problematic to implement (the prolog is not, but the epilog IS), but it will tend to eat up a significant amount of disk space on the server's A-disk if a lot of people start using the feature. Peter, what's the projected size for these files? Would you want the file to be LOCAL to a given server or global to all servers? Would you want a way to force all GET commands from people at your node to pass through this JCLPROLOG thing or not? If not, the files could easily be made local and it would perhaps not each that much space -- that is, if the individual JCLPROLOG files are not too large. That's all for today I guess... Eric