The LISTSERV mail forwarding package has been improved in an attempt to support this brain-damaged operating system sold by IBM and known under the name of VM/ISF. The following changes have been introduced: - A new configuration variable, FWD_FM, has been provided to let the installation choose the filemode of the disk where FORWARD FILE (the file containing all the mail forwarding settings) is kept. If this points to a R/O disk, it will be automatically reaccessed before any reference is made to the file (well LSVFILER would do it anyway, if you have a recent version), and LISTSERV will reject any /FORWARD command which would result in a write to the file, pointing you to the disk owner (as per a CP Q LINK command). The default filemode is 'A1', in which case the program acts exactly as before as far as the user is concerned. - Statistics are now gathered in a private file, FWDSUM FILE A1, regardless of the filemode of the disk housing FORWARD FILE. This has also another advantage: if a user cancels his forwarding and sets it back, the stats about the number of files he got forwarded are not lost. NOTE: if you migrate from the old FORWARD package to the new one, you will have to create this FWDSUM FILE from your old FORWARD FILE if you don't want to reset your statistics (to do this, just copy any non-blank, non-comment line in FORWARD FILE into FWDSUM FILE, removing the second word as per a "Parse var input a . b; Queue a b"). If you install the package from scratch, you need not be concerned as the file will be created automatically. If you have a VM/ISF system, you can set up one shadow LISTSERV machine per additional CPU in the complex, with the FORWARD FILE on a R/O link to the master machine's 191. This will allow mail to be forwarded correctly, whatever the CPU where the spool file was created. This is what IBM calls "Single Image" - if you want to know the list of the reader files of user X, you have to successively logon to each of the CPUs, do a Q R ALL X there, and sum up the results. Note that Q F X will return the value of some internal counter (number of spool files physically on the CPU, be them copied elsewhere or not, + number of spool files on another CPU for which we happen to have a shadow copy of the SFBLOK). This number has no actual meaning at all, so that if you sum up the Q F X counters you will get a number between 1 and N times the actual number of files owned by the user, where N is the number of processors in the complex. I wish the IBM operating system developers would plug in their brains before they start working. I thought the CMS5 windowing system was the most appallingly rotten rattle-brained thing IBM had ever dared to produce. It looks neat when compared to VM/ISF. The worst being that the VM/ISF syndrome does not affect only the VM/ISF customers. It affects everybody as code has to be put in standard products (like VM/HPO or LISTSERV) to support it. Oh well, I should probably go to bed before I get too much worked up :-) Eric