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.

[Steven Schweda]

Why should MOUNT /FOREIGN be worrying about
the data on the disk? Isn't that _my_
business?

Sounds more like a bug than a feature to me.

[Steven Schweda]

If I do MOUNT /FOREIGN on a large hard disk,
should I come back the next day because some
bug says that the whole thing needs to be
scanned for some special data which may or
may not be there, and which may or may not be
of any interest if it is there?

I don't think so.

So, why for a floppy?

[Volker Halle]

Steven,

the MOUNT/FOREIGN search for the home block is limited to the first 255 blocks (HM2$C_LIMITED_SEARCH_LENGTH) on the disk. You won't probably recognize the delay when mounting a real disk, but for a floppy, it does take some time.

AFAIK this is meant to try to do additional security checks, if a home block would be present and found.

Volker.

[Christopher Blackburn]

Does anyone know if there is (or will be) a patch to fix this problem as our system relies on the PCDISK utility program to read/write data file to floppy disk to upload to a hellicopter. The 3 1/2 minute mount delay will cause a few users to frown.

[Ian Miller.]

you could try mtools or MGPCX
ftp://ftp.process.com/vms-freeware/fileserv/mgpcx.zip

but if they use the $mount system service the behaviour will be the same.

[Volker Halle]

Christopher,

if this 'behaviour' change caused by V8.2 - and it certainly is noticable - affects your application or business, please consider to log a case with HP support.

We have analyzed and pin-pointed the problem, so it should be sent straightforward to OpenVMS Engineering.

Volker.

[Volker Halle]

Christopher,

this issue is now also being discussed on comp.os.vms

http://groups.google.de/group/comp.os.vms/browse_frm/thread/69a90f0c43fb63a8/d3171b757012678e?hl=de#d3171b757012678e

Volker.

[Christopher Blackburn]

Thanks Volker,

We have raised the problem with HP Engeneering support through our supplier so hopefully there will be a patch available in the future.

[Volker Halle]

This problem has now been solved in VMS83A_MOUNT96-V0200 and VMS83I_MOUNT96-V0200.

Volker.

[Christopher Blackburn]

Volker,

Thanks for update, we have got the patch and it fixes the problem.

Many thanks for your time.