To support DISK DUMP format in LISTSERV, I will be forced to make use of the (nonstandard) YDISK program to download the file. "DISK LOAD" does not support a "fn ft fm" indication (not even "fn ft"), and even though I can still COPYFI- LE the file to the required destination, something might have been destroyed on the A-disk. For example, I receive a DISK DUMP file saying "ERIC NOTE" (on the Q R ALL * command) which is in fact a PROFILE EXEC (and LSVDDFID will show it as such :-) ). LSVXMAIL wants it received as LISTSERV CMSUT1 D. With YDISK, all I have to do is "YDISK LOAD LISTSERV CMSUT1 D"; but with DISK, the only way is "DISK LOAD" and zap, here goes my PROFILE EXEC A1.... Bless IBM for not suppor- ting that *stupid* and *useless* "fn ft fm" argument... Now here is the problem: although YDISK is written by IBM, it is not part of VM/SP; although I could distribute it to all the recipients, it might, or might not, work on SP4. As far as I know, both DISK and CARD use the FCOPY algorithm for writing the file, and both had consequently been updated for SP4 for the hash table support. Now I can't swear that YDISK has been updated too, nor can I say for sure whether it HAD to be updated or not (if it just uses WRBUF, the SP3 version would work under SP4). To those of you who have SP4: please do a BROWSE YDISK MODULE and then /RENAME. If it doesn't say target not found, YDISK has been updated for SP4 (and please send it to me! :-) ). Otherwise it has not ... but it might still work on the D-disk (if there are less than N files, no hash table is created, and the D-disk usually contains less than 3 files). Ah well... *sigh* If we REALLY get into a problem with this, I'll take the SP4 DISK command and add support for "fn ft fm" myself (and an option to SKIP loa- ding -- a built-in LSVDDFID, so to speak), but I'd like not to have to do that. :-| Oh, a typical IBM exerpt from HELP CMS RECEIVE. They *are* aware of the secu- rity problem caused by DISK LOAD.... and they have a solution for it. No com- ment. *-----------------------------------------------------------------------------* (HELP RECEIVE, usage note 2. Why should I use RECEIVE? (* to eat more CPU *) ) Note that if multiple files are sent with continuous spooling (using CP SPOOL PUNCH CONT) and a series of DISK DUMP commands, RECEIVE recognizes only the first file identifier (filename and filetype). Any files have the same file identifier as existing files on your A-disk will overlay those files on your A-disk. As a sender, you can avoid imposing this problem on file recipients by doing any of the following: a. Always use SENDFILE, which resets any continuous spooling options in effect. b. Do not spool the punch continuous. c. If you must send files with continuous spooling, warn the recipient(s) that files are being sent in this manner and list the file identifiers of the files you are sending.