LD 9.2 invalid media format errors after install on VMS 7.3-2

[Francis Gribbin]

LD is new for me.

I want to install python. I've followed the recommendation and instructions in

http://www.vmspython.org/DownloadAndInstallationPython

Since LD CLI definition was not available with this version of VMS, I downloaded LD version
9.2 from digiater.nl and used
PRODUCT INSTALL LD

This looked like it worked. LD HELP did show
help.

I've run @SYS$STARTUP:LD$STARTUP and amended system startup but havn't rebooted the machine.

Having downloaded and unzipped the python LD
images I have
JFPLIB0003.DSK;1
JFPPY0013.DSK;1

When I try to connect I get media errors

$ ld CONNECT JFPPY0013.DSK lda2:
%LD-F-DETECTEDERR, Detected fatal error
-SYSTEM-F-FORMAT, invalid media format
$

In case the .dsk files were corrupt I tried an example from LD HELP EXAMPLE

$ LD CREATE /SIZE=8192 USER.DSK
$ LD CONNECT USER.DSK LDA1:
%LD-F-DETECTEDERR, Detected fatal error
-SYSTEM-F-FORMAT, invalid media format

Perhaps its worth noting the that LD version
command fails too

$ LD VERSION
%LD-F-DETECTEDERR, Detected fatal error
-SYSTEM-F-ILLIOFUNC, illegal I/O function code

Has anyone seen this sort of behaviour?

[Hoff]

Reboot the machine, and see if it works better. There is a reasonable likelihood that there was already a version of the LD device driver connected on the box.

[Hein van den Heuvel]

Hello Francis,

So far you only told us about the management tool and its commands. How about the DRIVER?
It should have been loaded when you executed
sys$startup:ld$startup.com

Please check with $SHOW DEV LD
There should be an LD0:
If it is not there, make sure that the driver image is there and has a reasonable date:
$dir/date/size sys$loadable_images:sys$lddriver.exe

fwiw,
Hein.

[GuentherF]

Sounds like the prevous LD version was running and you haven't rebooted after the installation of the new kit. Unfortunately the LD installation doesn't tell you that.

The new version has a different layout of the container file. This is what the error message is trying to tell you.

Guenther

[Hein van den Heuvel]

Hey Guenther, I beg to differ. Bad prior drive, maybe. But I would think that if there is a drive, then there is the command and that supposedly was not there.
But the container file surely is a simple range of blocks, with no meta-data applied!
And even if there was meta data, for which I can not se an excuse or reason, the still there is just no way Jur would build something which was not backwards compatible right?!
tgif,
Hein.

[Steven Schweda]

> But the container file surely is a simple
> range of blocks, with no meta-data applied!

I'd expect that anything else would defeat
the use of LD for CD/DVD creation, and that's
been tested pretty well by more than a few
people. (I think that even I've done it once
or twice.)

[Jon Pinkley]

Francis,

Since the LD VERSION command isn't working, it appears that there is an old version of LD installed, or perhaps the command definition isn't in synch with the ld$utility program.

Can you please enter these commands, capture them and paste the output to a text file (for example with notepad on a Windows system), save to a .txt file, and attach to a reply.

$ directory/full 'f$parse("ld$utility","sys$system:.exe")
$ anal/image/sel=(id,build,link) 'f$parse("ld$utility","sys$system:.exe")
$ directory/ful sys$loadable_images:sys$lddriver
$ anal/image/sel=(id,build,link) sys$loadable_images:sys$lddriver.exe

If you have Joe Meadow's VERB program, available on the VMS Freeware V5 or http://vms.tuwien.ac.at/freeware/VERB/, the output of the following would also be useful:

$ verb ld

Jon

[Jon Pinkley]

>>>But I would think that if there is a drive, then there is the command and that supposedly was not there.
>>>But the container file surely is a simple range of blocks, with no meta-data applied!

For disk devices there is metadata, but it is stored in the file header of the container file, not in the data blocks mapped by the retrieval pointers.

You can see this if you do a dump/header on the container file. The metadata is stored in the user reserved area.

The metadata stores attributes like geometry and whether the device with be a read-only device.

This was added in V7.0

$ help ld new_features_v7.0


LD

New_features_V7.0


There are new CREATE qualifiers:

/TRACKS=nnn
/SECTORS=nnn
/CYLINDERS=nnn
/MAXBLOCKS=nnn

These settings will be stored in the containerfile as metadata
(in the fileheader), and if present will be used when the
containerfile is connected (unless /NOAUTOGEOMETRY is specified).

rest of new features removed, but you can enter the command if you have ld installed.

[Jur van der Burg · Accepted solution]

Right, time for me to step in.

You're running the new LD control utility, but with an old driver which was apparently already active. Reboot the system, make sure LD$STARTUP has been run and do LD VERSION. It should work then.

There's no metadata in the container file itself for virtual disks, it's stored in the file header as John P. pointed out. There is metadata file stored at start start of a tape container file, but it has version information in it so that if the format changes I can maintain backward compatibility
.

I've been working for VMS too long to make that mistake! Backward compatibility is important (unlike some other software companies may think). A close look at the sources of LD will reveal that the connnect interface has had a big change in V9.2, but the old interface will work as well so that external application won't break.

Guenther's suggestion about a check if the driver is active in the installation procedure is a good one. I'll make sure that that's added to the next version.

Jur (LD author).

[Francis Gribbin]

Thanks for all the help.

I've rebooted and LD is working fine.

I've attached information about the files.