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