The 1.5j version of LSVSFILE contains some enhancements that will speed up GET commands by a factor of 2-4 (average) and PUTs by about 60%. The main differences with respect to the 1.5i version are a) the use of LSVFILER instead of EXECIO to read FILELISTs and b) an important design improvement that consists in reading the filelist up to three consecutive times to search a filelist entry (yes, that's an *improvement*, you'll see :-). LSVFILER has been extended to allow FIND and LOCATE options (much like EXECIO, but without delimiters), two interesting NONUM and NODATA options to avoid getting stacked/stemmed line numbers (or line data) when you don't need them, and, much more important, an ALL option that returns all the lines satisfying the target search, not only the first one (compare that with EXECIO... :-). As I said, LSVSFILE searchs each filelist for a matching fn ft entry up to three times: the first one it searchs for fn ft directly; then it searchs for generic fileids matching fn ft; and finally, it searchs for all 'true' filelist entries (ie, '/F' flagged) and enters recursion if needed. To avoid the overhead associated with reading a file thrice, a new set of options has been developed to allow keeping in-storage copies of a file upon request. This means probably a bit more of paging but reduces substatially I/O and wall clock time. Note that as filelists become larger and more nested the new LSVFILER gain becomes also percentually greater, while it is neglible for flat filelist spaces. -----> Those of you who hate statistics can stop reading here <----- The following figures were obtained via #CP Q T + GET|PUT + #CP Q T by subtraction. The following LSVSFILE versions were benchamrked: 1.5i, 1.5j (ie 1.5i + LSVFILER), 1.5j+ (1.5j + read the file thrice ---> avoid having to filter with rexx), 1.5j++ (1.5j+ with the in-storage file option). Scenario: * LISTSERV FILELIST is 158 lines long * INTERN FILELIST is a child of LISTSERV. It appears at line 235 and there are 64 filelists before it on LISTSERV FILELIST. One of these has 1140 lines. INTERN itself has 1083 lines. * M FILELIST is also a child of LISTSERV. It has 1140 lines, and appears at line 132 in it (61 filelists before). * SERVINFO FILELIST is a child of INTERN. To make things worse, I've put it just at the bottom of intern, ie at line 1083. There are no other childs of INTERN. Servinfo has 249 lines. * VMFSTK HELPCMS is a 67 lines file located at the bottom of M FILELIST. * TEST TEST is a test file. It's the first file on LISTSERV FILELIST, line 39. * MAILBOOK INFO is the last line of SERVINFO filelist. * NETMONTH 1986* is a generic entry on SERVINFO (line 60+). I've put NETMONTH 1986NOV (800 lines). * CON MODS is a 55 lines file declared in INTERN FILELIST, line 178. Here are the numbers (vtime/ttime): 1.5i 1.5j 1.5j+ 1.5j++ ------- ------- ------- ------- GET VMFSTK HELPCMS 3.20/4.35 2.91/3.63 1.23/1.96 1.20/1.90 GET VMFSTK HELPCMS M 2.24/2.85 2.05/2.69 0.81/1.46 0.81/1.46 GET TEST TEST ›LISTSERV! 0.55/1.40 0.50/1.10 0.50/1.10 0.50/1.10 GET MAILBOOK INFO look!! ---> 7.46/8.28 6.70/7.05 2.09/2.86 1.98/2.66 GET MAILBOOK INFO SERVINFO 0.90/1.80 0.91/1.83 0.66/1.32 0.86/1.77 PUT NETMONTH 1986NOV SERVINFO 5.29/6.46 4.84/6.11 2.86/4.07 2.82/4.02 PUT COM MODS INTERN 2.96/3.72 2.15/3.01 1.83/2.72 1.85/2.75 Notes: 1.- GET MAILBOOK INFO is the most improved. It's also the most nested. 2.- I'm a little surprised of the 1.5j++ to 1.5j+ comparison for GET MAILBOOK INFO SERVINFO. Perhaps that's the extra overhead generated by reading 1000+ lines into storage. Anyway, clock time is much improved in all cases, even if there is a slight increment of cpu time for 1.5j++. 3.- I've not had time to test PUTs without the filelist parameter. Jose Maria