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.
|