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.