On 2/20/19 1:25 PM, Glen Slick via cctalk wrote:
On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
<cctalk@classiccmp.org> wrote:
Theoretically, the SIMH emulated RA81 and the CMD emulated real
disk RA81 should be the same size because they are both supposed
to be RA81's.
I spent the time to get set up and verified that this assumption is
not correct. The CMD CQD MSCP SCSI controller firmware RA device type
feature appears to only change the reported MSCP media name string,
and has no effect on the reported MSCP size and geometry information.
I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
As far as I know the CQD-420 and the CQD-220A (but not the original
CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
in capacity, 2,147,483,648 bytes, 4,194,304 blocks.
......
Paul K's explanation and Glen's example matches my own experience in
this area. I don't have a CMD controller, but I move images between SIMH
and both Emulex UC07 and Dilog SQ706A MSCP/SCSI Controllers. I've used
RT11, XXDP, RSX11M+ and VAX VMS on both physical hard drives and SCSI2SD
emulated disks.
The physical SCSI drives I use have SCSI reassign capability. This
allows the controller/drive to manage media defects. This is
transparent to any of the OS'es. The controller presents the disk simply
as a continuous logical disk of disk blocks and the geometry has no
effect. Space reserved for bad block replacement is not visible to
the OS.
I make sure the number of logical blocks is maintained exactly as I move
the images back and forth between SIMH and physical Machines. The disk
type RA90, RA81, etc never makes a difference. The MSCP controllers
read the media size directly and report the disk logical capacity to VMS
Drivers.
If I move an VMS ODS-2 SIMH disk image to a larger SCSI disk drive then
problems will occur. For ODS type volumes, my understanding is that
bitmap.sys file won't have room to manage the extra space. I also try
to avoid edge cases for disk sizing that involve powers of two - e.g.
2**32. In my general experience, I have found boundary check problems
in different situations (especially non-Digital).
Disk NASTY$DKA100:, device type DEC RA92, is online, mounted, file-oriented
device, shareable, error logging is enabled.
Error count 0 Operations
completed 2653
Owner process "" Owner UIC
[SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 48 Default buffer
size 512
Total blocks 7603200 Sectors per
track 63
Total cylinders 474 Tracks per
cylinder 255
Volume label "VAXVMS73" Relative volume
number 0
Cluster size 9 Transaction
count 155
Free blocks 3072564 Maximum files
allowed 419336
Extend quantity 5 Mount
count 1
Mount status System Cache name "_NASTY$DKA100:XQPCACHE"
Extent cache size 64 Maximum blocks in extent
cache 307256
File ID cache size 64 Blocks currently in extent
cache 307161
Quota cache size 0 Maximum buffers in FCP
cache 557
Volume owner UIC [SYSTEM] Vol Prot
S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-2, subject to mount verification, protected
subsystems
enabled, file high-water marking, write-through caching enabled.
I don't see a discrepancy on SCSI2SD V5 cards between configuration size
and VMS reported block, The size used is recorded on the SCSI2SD V5
card. The SCSI2SD V6 adapters store the drive configuration on the last
block of the microSD and I believe reported capacity is reduced by 1.
Perhaps the CMD is doing similar to allow the media to be interchanged
between controllers.
Jerry
