LSV$PROF has now been replaced by a set of SYSVARS files which define the various LISTSERV system variables. I got tired of the old system which had two main drawbacks: 1) I had to resend LSVPROF which each new release or sub-release, because that's where the 'release' variable is defined. LSVPROF was quite large. 2) 50% of people used to forget to update the GLOBALV SELECT LISTSERV PUT statement in LSV$PROF after adding a few more assignments, and I got tired with explaining this. 3) I also got tired of adding more and more IFs in LSVPROF to supply default values for missing variables in case the postmaster has "forgotten" to update his LSV$PROF. So you have a SYSVARS FILE which list the various data files that are being inspected, and one or more xxxx SYSVARS files containing assignments and control statements. At present I have defined SYSTEM SYSVARS, common to all LISTSERVs, BITEARN SYSVARS, common to all BITNET/EARN servers, LOCAL SYSVARS which obsoletes LSV$PROF, and BITEARN2 SYSVARS which performs some verifications on what LOCAL might have forgotten to do. LSV$PROF is still called if it was found to be present, so it should be compatible, except that only those variables that existed in the STANDARD 1.5j LSV$PROF will be fetched from LSV$PROF. If you had locally-defined variables, they will be ignored and you'll have to migrate them to LOCAL SYSVARS. I will provide a SAMPLE SYSVARS file to be used as a template for your LOCAL SYSVARS. Another advantage is that whenever new variables are defined, the migration exec will send a SYSVARS template to the postmaster and tell him that these variables have been defaulted but ought to be merged into the LOCAL SYSVARS file if you want to override their settings. This should get rid of the boring "File LSV$PROF NEWEXEC must be inspected and merged into LSV$PROF EXEC". Another new feature is a new module, LSVIUCV, which replaces and obsoletes WAKEUP MODULE. I got *really* fed up of inquiries as to whether this was a licensed module or not. We have IPF here and we DO have a WAKEUP MODULE, but it's labelled release 3 and doesn't accept the IUCVMSG option. The one LISTSERV presently uses is release 5.35, which bears no copyright indication. Rumour has it that this is an IBM internal use only improvement to the official IBM program. Another rumour is that it has been written by some VM hack who kept only the IBM program's syntax. Anyway LSVIUCV is 100% IBM copyright free and this solves the problem completely. LSVIUCV only handles a subset of WAKEUP's functionality, and contains additional functions which specific to LISTSERV. Notably, it will perform all the message/file pre-parsing work and directly return a userid@node to the caller. It will also perform the list userid reader file stealing operation itself, and ONLY when this is required (ie just before deciding that it must enter wait state). This has given impressing results: it took 21/29 secs (VCPU/TCPU) to LISTSERV to process 50 'nop' commands to LISTSERV with the WAKEUP-based routine. The new LSVIUCV-based LSVPROF takes only 14/15, ie about 50% savings. LSVIUCV also allows LISTSERV to save all pending commands/messages in a file before logging off when a STOP command is being processed. These messages/commands are placed in a "Warm start data file" and are subsequently reloaded when LISTSERV is restarted. When restarted from a physical terminal, LISTSERV will ask you whether you want to perform a WARM or COLD start if these data are present. You can also ask to VIEW them, POSTPONE their reloading until the next startup, or SHUTDOWN immediately. POSTPONE is probably the best choice when you have just installed a new release and don't know how long it will survive :-) The reply is automatically WARM if LISTSERV is started in disconnected mode. I expect to see problems on those nodes where the format of the 'CP Q U' command output has been modified as LISTSERV might then think that it is not disconnected, so you should be aware of that read if your site has that kind of CP mods. To ward off the heavy rain of requests that fell upon me when I announced RELIUCV a long time ago, I am not going to make LSVIUCV a public domain program, least of all spend time modifying it so that other programs can use it. It is too specific to LISTSERV to be usable by other applications, and it was already too much *boring* work to write it without getting inundated with RFMWs (Request For More Work), "if you just added an option to (...) it would be so useful to my Super-Talk program", "with just a very small mod to the startup code you could (...)" No. I just don't have time, period, don't waste yours in asking :-) Eric