[Info-vax] FTP FYI

[Stephen Hoffman]

On 2020-11-21 20:24:00 +0000, Jeffrey H. Coffield said:

> I was moving savesets from one OpenVMS system to another one during a 
> data center migration using (not my choice) an Amazon ftp service and 
> found that on occasion a saveset file would not restore on the new 
> system. I got this error :
> 
> %BACKUP-F-INSBUFSPACE, insufficient virtual memory to accommodate 
> minimum buffer count
> 
> Googling the error provided no help. After digging into the problem I 
> discovered the save sets in question had the correct file size but 
> contained nothing but nulls. Re-pulling the files from the ftp server 
> corrected the problem.
> 
> It was not a case of pulling the files too soon as the restore command 
> was only started until after the entire file had been pushed.


Fodder for OpenVMS enhancements from this thread...

BACKUP should restore a /NOBACKUP file with some generic "There's 
nothing here because..." text embedded in the middle of the first 
sector. Though there's probably some app somewhere that's somehow 
dependent on finding a null file, per Hyrum's Law.

BACKUP saveset input handling already has issues including around RMS 
metadata, and this buffer-count error case seems a different variation 
on that same mess. Squabbling over stuffed-up RMS metadata is 
unhelpfully recalcitrant at best. Issue a diagnostic at most, and keep 
going. Or here, badly detecting a hosed saveset header.

However...  Updates to BACKUP seem nonsensical longer term, as the 
current app design is close enough to its performance limits to not 
matter. What might replace BACKUP and when, we shall eventually 
learn... And whether the hypothetical new BACKUP replacement can read 
BACKUP savesets for the purposes of restoration, or whether the 
existing BACKUP tools and BACKUP API and the BACKUP-related issues and 
limits linger on for the foreseeable future.


-- 
Pure Personal Opinion | HoffmanLabs LLC