Reading DVD written on W10 PC under V/I64?

[Rod Regier]

Is there a way to read a DVD written on a Windows 10 PC thru
OpenVMS/I64 8.4?

I know about MOUNT/MEDIA_FORMAT=CDROM for ISO-9660 CDROMS.
Apparently most field-recorded DVD's are in UDF format (not ISO-9660).

https://en.wikipedia.org/wiki/Universal_Disk_Format

I'm archiving OpenVMS BACKUP .BCK container files that have been ZIPped
and then written to optical media on a PC workstation.

It would be handy to be able to directly restore those ZIP files
on OpenVMS nodes.

[Stephen Hoffman]

Sure. But you already know how. Load the disk on a Microsoft Windows
system or another box that supports the format used, and transfer the
files over to OpenVMS via the network. Or tell the Windows system to
generate the files using ISO-9660:1988, if whatever tool you're using
here even allows that. "No built-in support exists within OpenVMS for
creating nor reading those features of ISO-9660:1999 not in
ISO-9660:1988, nor for various extensions to ISO-9660:1988 including
Joliet, Rock Ridge and HFS." But as for UDF support on OpenVMS, it's
not available. There was a third-party product from the folks at
USDESIGN — the whole web site is gone — that had something related
years ago but I've never encountered that product and don't know if
it's still around in some form. There are also open-source and
third-party tools for writing CDs can support the format. Just not
reading it and recovering the data on OpenVMS, AFAIK.

Related...

https://groups.google.com/d/msg/comp.os.vms/3h6onAJepps/us8fQjd7Z5UJ

In short, the answer hasn't changed since some bozo posted the following:

https://groups.google.com/d/msg/comp.os.vms/tLKFJo66vv4/V5hMfRF85mMJ

If you're re-doing this media creation process to switch over to
ISO-9660:1988 sans extensions, I'd probably also get rid of the BACKUP
savesets (or would create a parallel set of archives), and would use
zip 3.0 or later (as available) on OpenVMS with the "-V" switch.
Quote that switch, or use extended parsing. Removing the BACKUP
wrapper means that other systems can at least access the text files in
the archive, without having to scrounge up and get BACKUP or an
open-source tool that can (sometimes) read BACKUP savesets involved in
the restoration. Less work, fewer tools, etc.


--
Pure Personal Opinion | HoffmanLabs LLC

[Steven Schweda]

> [...] a DVD written on a Windows 10 PC [...]

Written _how_, exactly? I'd be willing to bet that
there's more than one program which can do this.

> I'm archiving OpenVMS BACKUP .BCK container files that have
> been ZIPped and then written to optical media on a PC
> workstation.

As usual, many things are possible, including creating an
optical disc (CD, DVD) image on the VMS system, and doing
only the actual disc writing on the non-VMS system. I'd
guess that one might use LD, and make an ODS5 image, or
mkisofs (part of cdrtools) to make an ISO-9660 image, or ...

[Scott Dorsey]

In article <60169935-5892-4493...@googlegroups.com>,

Steven Schweda <sms.an...@gmail.com> wrote:
>> [...] a DVD written on a Windows 10 PC [...]
>
> Written _how_, exactly? I'd be willing to bet that
>there's more than one program which can do this.

Likely it's a big FAT filesystem, which is the common DVD standard.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Stephen Hoffman]

On 2017-06-21 21:29:56 +0000, Scott Dorsey said:

> Likely it's a big FAT filesystem, which is the common DVD standard.

I've not encountered somebody with a FAT-format recorded-media optical
disk with Windows tools, though stranger things have happened.

I've been handed more than a few ISO-9660:1999 optical disks, quite
possibly using UDF. Commercially recorded video DVD disks tend to be
UDF, too.

And OpenVMS doesn't know from UDF, nor from ISO-9660:1999, nor most of
the earlier ISO-9660 extensions.

https://en.wikipedia.org/wiki/Universal_Disk_Format

Yes, beyond dusting off and bringing MMOV forward, ISO-9660:1999 and
UDF support would (eventually) be additional areas requiring work, for
those folks that want to use OpenVMS as a client system. But VSI isn't
headed in that direction right now, per their comments.

[Steven Schweda]

> [...] I'd probably also get rid of the BACKUP savesets (or

> would create a parallel set of archives), and would use zip
> 3.0 or later (as available) on OpenVMS with the "-V" switch.

> [...]

Perhaps. If you depend on exotic features of the VMS file
system, then using BACKUP first might be safer. Zip 3.1d
(beta) should resolve various problems with odd-ball file
names ("a^.b."), ACLs bigger than 512 bytes, and a bunch of
other bugs, but Zip does not deal well with hard links or
aliases. (On VMS or any other OS.)

If your stuff is simple enough, then Zip ("-V") does have
those portability advantages. But I'd give some careful
consideration to whether exotic file-system features are in
use, and, if not, then I'd still run a real test on real data
before I trusted any program which lacks formal support and a
warranty. ("Trust, but verify.")

I use Zip and UnZip for many things, and they haven't
damaged any of my data since I fixed the old problems with
"-V" (Zip 2.32, 2004?), but I don't stress them much.