[Info-vax] From ODS-2 to ODS-5

[Stephen Hoffman]

On 2020-08-20 20:52:19 +0000, Arne Vajhj said:

> $ SET VOL/STRUCT=5 DKxn
> 
> supposedly should do it, but would it be "better" to backup data, init 
> disk and restore data?

You should have backups anyway, but the ODS-2 to ODS-5 "conversion" 
resets a constant in a field in the ODS volume data structures. Nothing 
more. Whack. Poof. Done. ODS-2 becomes ODS-5.
ODS-5 is a superset of ODS-2, and allows longer filenames and deeper 
directories and more varied characters and which means a data structure 
or three related to those (FH5 comes to mind) become permissible, but 
it's otherwise ODS-2.
The "conversion" doesn't need to do anything past setting info in the 
header that allows "Harder, Better, Faster, Stronger", whoops, wrong 
band, allows deeper directories, longer filenames, and more varied 
filenames.
Where folks get in trouble with ODS-5 is with older apps encountering 
newer and longer filenames, which means feeding those apps "subset" 
filenames, or updating the apps.
I've yet to encounter a case where "if it hurts, don't do that" 
strategy was difficult, when maintaining an old app pending app updates.
OpenVMS doesn't make filenames or pretty much anything related to RMS 
transparent unfortunately, meaning folks will find NAM$C_MAXRSS, 
hard-coded 255, and such scattered around apps.
(q.v. NAML$C_MAXRSS, etc.)
Filename parsing is a disaster, too. PCSI parsing was busted for years. 
Many apps are busted here too, absent groveling deeply in sys$parse.
The hypothetical addition of robust OORMS support would make most of 
this filename processing vastly easier.
But I digress.
Conversion from ODS-2 to ODS-5 is trivial.
Reverting from ODS-5 to ODS-2, now reverting gets to be more 
interesting (q.v. BACKUP), if you should encounter critical apps that 
somehow can't be distracted from what doesn't exist in ODS-2.



-- 
Pure Personal Opinion | HoffmanLabs LLC