Problems with PCDISK utility on VMS 8.2

[Christopher Blackburn]

Has anyone experienced problems using the PCDISK utility program supplied with VMS on 8.2.
The utility runs up with the "MCR PCDISK" command but when the "USE A: DVA0:" command is used it takes 3-4 minutes before the "A>" prompt is returned. After this initial delay import and export commands work at a reasonable rate.
The DVA0: device is a RX26 but I get the same problem on other Alpha platforms running 8.2. The utility was OK on issue 7.3.

[Volker Halle]

Christopher,

I'm seeing the same behaviour regarding the PCDISK> USE A: DVA0: command.

OpenVMS Alpha V8.2 on AlphaServer 1000A 5/400
PCDISK V6.0 (Image Ident: V7.3-140A 26-NOV-2004)

Using LDDRIVER trace, it can be seen, that every consecutive block (LBN) on the RX26 is read 2-3 times while the 'USE A: DVA0:' operation is in progress.

When using LD CONN DVA0:/REPLACE LDA1:, the operations finally fails with:

PCDISK> use a: lda1:
%PCDISK-E-ECONNECT, Error connecting drive A: as LDA1:
-PCDSHR-E-BADBPB, Non-DOS disk, or partitioned hard disk format

but the duration of the command is the same as with direct access to DVA0:

Volker.

[Steven Schweda]

Which version of PCDISK?

Does the LED on the floppy drive do
anything? When?

SHOW ERROR ?

If you get desperate, you might look into
mtools as an alternative:

http://antinode.org/dec/sw/mtools.html

Or MGPCX.

[Christopher Blackburn]

Version of PCDISK is V6.0-200B A11-14 and is dated 18-apr-2004.

During the USE command the floppy disk light is on contonuously. I suspect what Volker is saying is correct i.e. the number of IOs is larger that expected.
On my system the "A>" prompt does eventually return and IMPORT/EXPORT commands then work correctly. It just seems to be the USE command that causes the long delay.

[Volker Halle]

Christpher,

I also did get the A:> prompt eventually. And I could do a DIR of the MS-DOS floppy.

It just failed, when tracing the IOs with LDDRIVER, but this test at least explained what PCDISK was doing...

Volker.

[Steven Schweda]

Any change with a freshly formatted diskette?
Or one freshly formatted by PCDISK?

[Christopher Blackburn]

Steven,

I get the same slow response if the disk is formatted with a PC or via PCDISK.

[Volker Halle]

Christopher,

a simple $ MOUNT/FOR DVA0: also shows this behaviour. Lots of single block IOs. PCDISK is apparently calling SYS$MOUNT (MOUNTSHR is activated in the process). Can you still test this on an older version of OpenVMS ?

It would then be an OpenVMS MOUNT/FOREIGN (?) problem, as PCDISK is out of the picture.

Volker.

[Christopher Blackburn]

Volker,

Mount/for dva0: works OK on VMS 7.3.

My previous thread concerned a problem with the SYS$MOUNT system service and the LKWSETFUL error returned if the process quota is not large enough. It would appear that something has changed in the MOUNTSHR executable between 7.3 and 8.2.

[Volker Halle · Accepted solution]

Christopher,

it's a feature not a bug !

Due to changes made for I64 in OpenVMS V8.2 common sources (the home block of an I64 system disk can't be at LBN 1 anymore), MOUNT/FOREIGN will scan the disk for up to 255. blocks looking for a home block.

These 255. read-IOs (each read is also retried, resulting in about 500-600 IOs) take about 3.5 minutes on a floppy.

Volker.