[Info-vax] BACKUP to the null device

[Michael Moroney]

AEF <spamsink2001 at yahoo.com> writes:

>On Feb 9, 1:08 pm, koeh... at eisner.nospam.encompasserve.org (Bob
>Koehler) wrote:
>> In article <60590914-65b1-4990-a57c-fb8143f8a... at g11g2000vbq.googlegroups.com>, AEF <spamsink2... at yahoo.com> writes:
>>
>>
>>
>> > But what fails with BACKUP works fine with COPY:
>>
>>    BACKUP is not COPY.

>That was exactly my point.

>Michael (whom I responded to) said null doesn't make sense for copying
>to since you cannot make directories on it. But you "can" with COPY,
>as my demo which you snipped off demonstrates. IOW, his reasoning
>about why it doesn't work with BACKUP doesn't apply to COPY. So there
>must be another reason it doesn't work with BACKUP.

What I really meant is more on the lines that BACKUP was intended for
backing up files.  Its output, if not a saveset, is a set of files that 
are a backup of the input files.  Doesn't make sense on a mailbox.
(I just played around, the NL: behavior is the same as to an ordinary
mailbox, BACKUP won't do it unless you add a /SAVESET [and then the 
mailbox must accepr records large enough])

Copy is for copying things, it figures out that directories don't
make sense on a mailbox (null or not) but figures you want to copy
the data.  (Again, I think all this behavior is on the RMS level,
but BACKUP doesn't use RMS except for savesets, sometimes)

It seems BACKUP has specific behaviors for different device types.
Tapes are treated specially (as savesets without /SAVE, but handled
differently), mailbox-types I just mentioned, and for giggles I
tried backing up to terminal TTA0:.  It refuses, with or without /SAVE
(hey, what if I have some weird saveset-writer thingy on the end of an 
RS232 link?).