On 2/16/19 12:35 PM, Zane Healy via cctalk wrote: OK, as usual, I hac caused confusion and didn't get my point across. let's try with a detailed explanation of what I did that didn't seem to work. First, my hardware. I have a PDP-11/93 with a CMD SCSI Module and a BA350 with 6 2GB hard drives. The Module is set up to present RA81 disks and the first 3 disks have 4 partitions each which should work out to 12 RA81 disks. (But that last part is unimportant right now!) I used SIMH to build RSTS V9.6 on a simulated RA81 disk. I wrote the disk as a file to a CDR in CD9660 format. I moved the BA350 and the CD to a VS3100 running OpenBSD. I was able to mount the CD under OpenBSD and see the file containing the disk image. I used dd with the command given in my original message (and repeated above) to try to write the image to a real SCSI disk. When I try to boot it I get the RSTS Message "INIT.SYS not found". The disk was completely blank to start so the RSTS info must have been copied but apparently not copied correctly. Any more suggestions? bill

On Sat, Feb 16, 2019 at 10:53 AM Charles Anthony <charles.unix.pro at gmail.com> wrote: Did some reading up on the RA81 and looked at the relevant SIMH code; it looks like the MSCP protocol is using Logical Block Addressing, which would tend to disprove my sparse disk speculation. -- Charles

On 2/16/19 3:57 PM, Zane Healy wrote: I guess I don't understand where you are getting bootable CDROM install media for any PDP-11 OS. I am not aware of any PDP-11 that supported CDROM as a boot device either. Might be interesting to try. I have the manual. I only chose RA81 as it was the biggest size disk supported by all the PDP-11 OSes. I would love to use bigger but you have to pick one in the configuration of the controller. You can choose to not emulate anything but I expect most PDP-11 OSes would have a problem installing to a very large, unspecified type, disk. I have a CQD=220A/MT configured for 6 disks and one tape. As for disk types, you can toggle RA ON or OFF on each drive. You can specify one RA type that will be in effect for any disk with RA ON. Types are: RA70, RA80, RA81, RA82, RA90 and RA92. OSes supported are VMS, Ultrix, Unix/Berkeley, RSX-11M, RSX-11M-Plus, RSTS/E, RT-11, DSM-11, ISM-11, TSX+, VAXELN and AT&T UNIX. Most recent versions of all of them. Or so it claims. The only OS I have ever had running on one of these cards was RT-11. I am just now getting around to trying to play with other OSes to see if they actually work. But, getting the OS onto the machine is a challenge all in itself, bill

I'm not sure which comments you're replying to. For the case of RSTS, small or large is not a consideration. What matters, as I mentioned, is that RSTS has a file system layout that is dependent on the device size. So (unlike some other file systems like FAT32) is isn't always valid to do an image copy from one device to a larger device. If the input and output devices are the same size, and error free, image copy is always valid. MSCP devices are error free; some older devices are also normally error free (like RK05 or RP03). It would be interesting if you can post the exact sizes in blocks of the SIMH image, and the real disk you copied it to. That would help confirm my guess that it's a size issue. If that's not the answer, it would be possible to use INIT ODT to catch the error and analyze what specifically it's unhappy about, but that's not straightforward. If you do have a size mismatch, fixing thatbefore you retry would be a good thing. RSTS doesn't have any released mechanisms for creating installation kits. Those scripts existed on the RSTS development systems. Possibly they can be found in source kits (which are rare). In the early days, RSTS came with a standalone image backup program: ROLLIN. Around V6 that was replaced by a file system aware standalone backup program: the SAVRES option in INIT. That was retired in V9 when the new fast BACKUP program was released. The reasoning here is that standalone backup isn't a feature -- instead, the feature is a way to do a full system restore starting from a dead system. RSTS does this by copying a few minimal features from the installation device: INIT.SYS, a monitor (such as SYSGEN.SIL), DCL, BACKUP, and perhaps one or two other files. Then you start that minimal system and issue a RESTORE command to restore everything from your backup. So there is no need for the maintenance headache of a "standalone" backup tool. SAVRES had a pile of hairy bugs and major maintenance headaches, and making a standalone PDP11 tool do streaming tape support was just way too painful. That's why V9 went the route of doing everything with BACKUP, since that's where the streaming support was added. The steps for bare metal restore go roughly like this: 1. Boot a kit 2. Use the DSKINT option to initialize the output disk 3. Use the COPY option to copy the minimal files to the output disk, which is then booted. 4. Start that minimal system on the output disk. 5. Use RESTORE to copy everything from your backup. I don't remember if there is a documented procedure for creating a minimal kit. For disk based ones, it's pretty simple: a. Initialize the kit device as read-only. b. Mount it, overriding the read-only setting. c. Copy the minimal files. d. Hook INIT.SYS. e. To test it, boot the kit; it should boot correctly and act as a kit (by offering to copy to the output device rather than by going to the usual INIT prompt). You can do this for any RSTS disk that's big enough, and for which INIT still has a boot loader. For example, even in V10.1 you can boot an RK05, so you can make an RK05 kit. If the device isn't big enough for all the minimal files, it gets a bit tricky but it still can be done; the Micro-RSTS RX50 based kit is an example. I don't have the details at my fingertips but I can dig them out if needed. paul

Yes, but you said 4 partitions on a 2 GB disk, which is rather different from the actual RA81 size. You could read back the copy and compare it with the original. But I can tell you that a properly executed image copy WILL work. I suppose one question is whether dd is actually such a program. If you change the transfer address in the boot block by +2, you'll be dropped into ODT immediately after INIT is loaded by the boot loader. You can then proceed from the break and ODT will be called again if a fatal error occurs (such as the "init not found" message). You can then look at the disk size table. Use PATCH on your SIMH copy of the system to find the address of DU$SZL and DU$SZM, those are the tables of low and high 16 bits of the device size for each DU unit (indexed by unit number). The number there will tell you what INIT heard from the controller. What kit device do you need? TU58, no -- that's not a file structured device on RSTS. RX33 is an RX50 in a different physical package if I remember -- 800 block MSCP device. That works fine, subject to the necessary tricks to get the files on the floppies and do the switching. Checking... The way it's done is that INIT.SYS has to be on the first floppy, of course, which is what you boot. Then the other needed files can be spread over other floppies as needed to fit (whole files per floppy). All but the last floppy contain a name.EOV file where "name" is the pack label of the next floppy to use. The content of the file is printed on the console as a prompt; it's a null terminated string. You mean build an initial system on a small disk, and then load the rest onto a big disk some other way? Sure, that should work fine. paul

Ok. That's may be big enough without volume switching, but in any case, if it speaks MSCP, RSTS will support it. (Well -- more precisely, if it speaks MSCP and have fewer than 2^23 blocks.) Yes, that will be fine. If the disk is RL02-ish in size it will be ample for this purpose. Even something as small as an RK05 can probably be made to do a basic job. paul

On Mon, Feb 18, 2019 at 6:18 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: The RX50 was a single sided 800 block floppy. The first two tracks had no interleave. The rest has 2:1 interleave, though sometimes physical and other times logical. Strange in some ways, kinda standard in others. But it's still a floppy, and other than size, much like the RX33 with 1/3 the number of blocks. Warner

On Tue, Feb 19, 2019, 7:24 AM Paul Koning <paulkoning at comcast.net wrote: The interleave is logical on the Rainbow. The drive is formatted to 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, however after track 2 they are logically interlaved by the drivers in Venix, Dos and CP/M. There is no skew there, except for Venix... And on the Rainbow, tracks are purely sequential... Guess that lead me astray for the pdp-11 users... The MSCP controller does this; on a Pro it's done in the driver. I've done I stand corrected. Yet another odd quirk of this quirky media. I recall Warner

On 2/18/19 10:59 PM, Glen Slick via cctalk wrote: Sure. I have a SCSI 9-track and a 1.4" QIC (TKZ-10) and even a SCSI TK50 if I ever get it fixed (but then we know how likely it is that any of the physical TK50 drives will actually work at this point in time!!) But all of these require TMSCP media and the only one I have ever seen (and actually have in my possession) is TK50. Yes, if I could get a TMSCP Install Kit on a 9-track tape. :-) I guess I was naive. I used to work with real RA drives in the past and figured the emulations were at least accurate enough to know how big the disk was. It wasn't a secret. All sounds like fun, but if the two emulations don't do RA81 correctly the information doesn't really do me much good. I certainly can't change the CQD's idea of what an RA81 is. I am sure once I successfully leap this hurdle the system will run RSTS nicely (I only wish I had the CIS option for one of my machines). Like I said earlier, good thing this is only a hobby. bill

On 2/19/19 12:37 PM, Glen Slick via cctalk wrote: I have a 220A/TM and it certainly does. Pages 4-10 thru 4-15 of the manual, particularly Configuration Options "A" and "1". Not familiar with the 220A/E it's not mentioned in my manual. Probably a much newer version. bill

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: Looking at the SIMH code: /* type sec surf cyl tpg gpc RCT LBNs RA81 51(+1) 14 1258 14 1 2856 891072 */ #define RA81_SECT 51 /* +1 spare/track */ #define RA81_SURF 14 #define RA81_CYL 1258 /* 0-1247 user */ #define RA81_TPG RA81_SURF #define RA81_GPC 1 #define RA81_XBN 2436 /* cyl 1252-1254? */ #define RA81_DBN 2436 /* cyl 1255-1256? */ #define RA81_LBN 891072 /* 51*14*1248 */ #define RA81_RCTS 2856 /* cyl 1248-1251? */ #define RA81_RCTC 1 #define RA81_RBN 17472 /* 1 *14*1248 */ I am presuming that (without actually checking) that these are the numbers returned to RSTS when it queries the disk; if these numbers are different then the h/w, then that could be an issue. I am a bit curious about "+1 spare/track" - I wonder if the h/w reports 51 or 52? -- Charles

On Tue, Feb 19, 2019 at 6:27 AM Paul Koning <paulkoning at comcast.net> wrote: Presumably SIMH is returning RA81_LBN (891072) as the device size; this is calculated based on the 51 sectors/track. If the h/w is returning a size based on 52, then there is a mismatch which could be the source of the problem. It has been hypothesised that the original problem is related to SIMH misreporting the disk size; I was trying to point out a possible source of error; does anyone know what size the h/w reports? -- Charles

On Tue, Feb 19, 2019 at 10:14 AM Paul Koning <paulkoning at comcast.net> wrote: I am concerned that the spare is the issue. If the track has 52 sectors, and one is reserved as a spare, is that spare included in the LBA calculation? If it is, then SIMH is wrong; the first sector of the second track written in the spare sector, throwing all of the remaining data out of alignment, with the symptom of RSTS booting but not being able to find INIT.SYS. If the spare sector exists and SIMH is not allocation space for it, then the disk image will not copy correctly with 'dd'. (However, dd might be coereced into doing the right thing with 'dd if=... of=... ibs=26112 obs=26624'; reading 512*51 byte records (a SIMH track) and writing 512*52 byte records (a RA81 h/w track)). -- Charles

On Wed, Feb 20, 2019 at 5:38 AM Paul Koning <paulkoning at comcast.net> wrote: Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the disk through MSCP in the case of the *hardware*. However, in the original posters case, the SIMH disk image is being copied to the RA81 drive without the benefit of the MSCP controller (if I understand correctly). This would lead to track misalignment and could result in the observed behavior. The SIMH MSCP emulation is not doing the spare sector correctly; it is not including the spare sectors on the RA81 disk image. -- Charles

On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk <cctalk at classiccmp.org> wrote: Re-reading the original post, it it not clear to me how the disk write was accomplished; I am not familiar with the mentioned hardware. If the data was written to the RA81 with a controller that correctly did the spare sector mapping, then my spare sector hypothesis is wrong. The reported symptoms sound like a disk geometry issue; the data passes through several systems on the way to RSTS, and it seems likely to me that one of the steps is damaging the data. As I lack experience with or access to the specific hardware, I am speculating about the exact failure mode. I do however believe that it is highly likely that disk geometry is the root of the problem. Having no no further specific ideas about the failure mode, I will shut up now. -- Charles

Typo. 8, not 9. DCS is a power of 2, the smallest value such that device size / DCS is < 65536. paul

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote: 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. After using the "Z = Reset Controller" configuration option to reset the CQD-420/TM firmware to its default state this was the configuration reported by the firmware: SCANNING SCSI DEVICES ATTACHED ... DEV0: DU0 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV1: DU1 SCSI ID 1 LUN 0 OFFLINE Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV2: DU2 SCSI ID 2 LUN 0 OFFLINE Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV3: DU3 SCSI ID 3 LUN 0 OFFLINE Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF, DEV4: MU0 SCSI ID 4 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV5: MU1 SCSI ID 5 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV6: MU2 SCSI ID 6 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV7 SCSI ID 7 HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF, Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA dev= DEF, Rsv/Rls Option ON,MSCP credit = 16,sync rate = 04 MB/sec, RSX FP OFF,Sel Timeout = 250 ms (PMR=Prevent Medium Removal WWV=Write W/Verify) Then a KA660 VAX console sees the device like this: UQSSP Disk Controller 0 (772150) -DUA0 (RA90) UQSSP Tape Controller 0 (774500) Then VMS booted on the KA660 VAX sees the device like this: $ MOUNT /FOREIGN BA215$DUA0: %MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0: $ SHOW DEVICE /FULL BA215$DUA0: Disk BA215$DUA0:, device type RA90, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 4194302 Sectors per track 217 Total cylinders 1933 Tracks per cylinder 10 Volume label "OVMSVAXSYS" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. One question here is why does VMS see 4194302 blocks when a SCSI Read Capacity command of the drive reports 4194304 blocks? Is the CMD CQD-420/TM firmware reserving a block or two? Anyway, I then tried to recreate the configuration of the original post as I understand it, partitioning the one physical SCSI drive into four logical MSCP device units, and turning on the RA81 type feature for those four MSCP device units. Note that now DEV0: DU0 through DEV3: DU3 all map the the same SCSI ID 0, they all have the RA feature set to ON, and the RA dev type is set to 81. SCANNING SCSI DEVICES ATTACHED ... DEV0: DU0 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV1: DU1 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV2: DU2 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV3: DU3 SCSI ID 0 LUN 0 IBM DDRS-39130D DC1B Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON, DEV4: MU0 SCSI ID 4 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV5: MU1 SCSI ID 5 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV6: MU2 SCSI ID 6 LUN 0 OFFLINE Disc ON,Sync ON,3-Density ON,Buffer ON, DEV7 SCSI ID 7 HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF, Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA dev=81, Rsv/Rls Option ON,MSCP credit = 16,sync rate = 04 MB/sec, RSX FP OFF,Sel Timeout = 250 ms (PMR=Prevent Medium Removal WWV=Write W/Verify) Now the KA660 VAX console sees the devices like this. The MSCP media name string has changed from RA90 to RA81. UQSSP Disk Controller 0 (772150) -DUA0 (RA81) -DUA1 (RA81) -DUA2 (RA81) -DUA3 (RA81) UQSSP Tape Controller 0 (774500) Now VMS running on the KA660 VAX sees the devices like this. It has simply divided the previous total block size of 4194302 into four equal block sizes of 1048575. It hasn't done anything to try to present the drives as the same total block size as a real hardware RA81 drive. $ MOUNT /FOREIGN BA215$DUA0: %MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0: $ MOUNT /FOREIGN BA215$DUA1: %MOUNT-I-MOUNTED, mounted on _BA215$DUA1: $ MOUNT /FOREIGN BA215$DUA2: %MOUNT-I-MOUNTED, mounted on _BA215$DUA2: $ MOUNT /FOREIGN BA215$DUA3: %MOUNT-I-MOUNTED, mounted on _BA215$DUA3: $ $ SHOW DEVICE /FULL BA215$DUA0: Disk BA215$DUA0:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "OVMSVAXSYS" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. $ SHOW DEVICE /FULL BA215$DUA1: Disk BA215$DUA1:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. $ SHOW DEVICE /FULL BA215$DUA2: Disk BA215$DUA2:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. $ SHOW DEVICE /FULL BA215$DUA3: Disk BA215$DUA3:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 1048575 Sectors per track 217 Total cylinders 484 Tracks per cylinder 10 Volume label "" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type.

After spending way to much time on this today, I verified that at least on the CMD CQD Q-Bus SCSI controller versions that I have if I wanted the CMD CQD controller to report an MSCP disk size of exactly 891072 blocks to match the SIMH emulated RA81 disk size, I had to soft resize the capacity of the SCSI hard drive to be 2 blocks larger, i.e. a capacity of 891074 blocks. This is with the CMD CQD controller reset to the default configuration with the 'Z' configuration option. The behavior of Q-Bus SCSI controllers from other vendors will be different. After doing that I verified that VMS on a VAX CPU, and also the 2.11BSD standalone disklabel on a PDP-11 CPU saw an MSCP disk size of 891072 blocks with the SCSI disk size of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller. I then installed RSTS/E 10.1 on a SIMH RA81 and then did the equivalent of a dd from the SIMH RA81 disk image file of size 456,228,352 bytes to the SCSI hard drive of capacity 891074 blocks. Then the PDP-11 CPU booted RSTS/E 10.1 from SCSI hard drive attached to the CMD CQD Q-Bus SCSI controller. Sorry for the extra long message. Gory details below. If I don't add the details now I'll forget all the details myself tomorrow. Resizing the 9GB SCSI hard drive down to a capacity of 891074 blocks on a Windows PC using sg3_utils-1.37 (I seem to recall that previously I tried this with a newer version of sg3_utils and something didn't work right): C:\sg3_utils-1.37>sg_scan PD0 [C] HDS728040PLAT20 PF1OA21B PD1 IBM DDRS-39130D DC1B CDROM0 [Z] TEAC CD-224E 1.7A C:\sg3_utils-1.37>sg_inq pd1 standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=1 Sync=1 Linked=1 [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=164 (0xa4) Peripheral device type: disk Vendor identification: IBM Product identification: DDRS-39130D Product revision level: DC1B Unit serial number: RE1X3474 C:\sg3_utils-1.37>sg_readcap pd1 Read Capacity results: Last logical block address=17849999 (0x1105e8f), Number of blocks=17850000 Logical block length=512 bytes Hence: Device size: 9139200000 bytes, 8715.82 MiB, 9.1392 GB C:\sg3_utils-1.37>sg_format --count=891074 --resize --verbose pd1 inquiry cdb: 12 00 00 00 24 00 IBM DDRS-39130D DC1B peripheral_type: disk [0x0] PROTECT=0 mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00 mode sense (10): pass-through requested 252 bytes but got 28 bytes Mode Sense (block descriptor) data, prior to changes: Number of blocks=17850000 [0x1105e90] Block size=512 [0x200] mode select (10) cdb: 55 11 00 00 00 00 00 00 1c 00 Resize operation seems to have been successful C:\sg3_utils-1.37>sg_readcap pd1 Read Capacity results: Last logical block address=891073 (0xd98c1), Number of blocks=891074 Logical block length=512 bytes Hence: Device size: 456229888 bytes, 435.095 MiB, 0.45623 GB Verifying that the SCSI hard drive with a capacity of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller is seen as a drive with a capacity of 891072 blocks on VMS on a VAX CPU: $ MOUNT /FOREIGN BA215$DUA0: %MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0: $ SHOW DEVICE /FULL BA215$DUA0: Disk BA215$DUA0:, device type RA81, is online, allocated, deallocate on dismount, mounted foreign, file-oriented device, shareable, available to cluster, error logging is enabled. Error count 0 Operations completed 4 Owner process "SYSTEM" Owner UIC [SYSTEM] Owner process ID 00000214 Dev Prot S:RWPL,O:RWPL,G:R,W Reference count 2 Default buffer size 512 Total blocks 891072 Sectors per track 217 Total cylinders 411 Tracks per cylinder 10 Volume label "OVMSVAXSYS" Relative volume number 0 Cluster size 0 Transaction count 1 Free blocks 0 Maximum files allowed 0 Extend quantity 0 Mount count 1 Mount status Process ACP process name "" Volume Status: Unknown ACP type. Verifying that the SCSI hard drive with a capacity of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller is seen as a drive with a capacity of 891072 blocks on the 2.11BSD standalone disklabel on a PDP-11 CPU (ignore the "45Boot" which is a 2.11BSD bug that is fixed in a newer patch to correctly report "53Boot" on an 11/53 CPU). 9 8 7 6 5 4 3 2 1 Commands are Help, Boot, List, Map, Test and Wrap. Type a command then press the RETURN key: BOOT MU0 MU0 45Boot from tms(0,0,0) at 0174500 : tms(0,1) Boot: bootdev=06001 bootcsr=0174500 disklabel Disk? ra(0,0) 'ra(0,0)' is unlabeled or the label is corrupt. Proceed? [y/n] y d(isplay) D(efault) m(odify) w(rite) q(uit)? D d(isplay) D(efault) m(odify) w(rite) q(uit)? d type: MSCP disk: RA81 label: DEFAULT flags: bytes/sector: 512 sectors/track: 217 tracks/cylinder: 10 sectors/cylinder: 2170 cylinders: 410 rpm: 3600 drivedata: 0 0 0 0 0 1 partitions: # size offset fstype [fsize bsize] a: 891072 0 2.11BSD 1024 1024 # (Cyl. 0 - 410*) d(isplay) D(efault) m(odify) w(rite) q(uit)? q Label changed. Discard changes [y/n]? y 45Boot from tms(0,0,1) at 0174500 : Booting RSTS/E 10.1 from the SCSI hard drive with a capacity of 891074 blocks attached to the CMD CQD Q-Bus SCSI controller after the SIMH emulated RA81 disk image file with the RSTS/E 10.1 was dd to the SCSI hard drive: 9 8 7 6 5 4 3 2 1 Commands are Help, Boot, List, Map, Test and Wrap. Type a command then press the RETURN key: BOOT DU0 DU0 RSTS V10.1-L RSTS (DU0) INIT V10.1-0L Today's date? 20-FEB-19 Current time? 19:46 Start timesharing? <Yes> <stuff deleted> RSTS V10.1-L 20-Feb-19 07:46 PM User: 1,2 Password: Jobs detached under this account: Job What Size State Run-time RTS 1 ERRCPY 5K SR 13.6 ...RSX 3 OMS 9K SL 1.6 ...RSX 4 PBS... 19K SL 1.6 ...RSX Job number to attach to? Last interactive login on 20-Feb-19, 07:46 PM at KB0: Last non-interactive login on 20-Feb-19, 07:46 PM 3 other users are logged in under this account $ SHOW DISK Disk Structure: Dsk Open Size Free Clu Err Name Level Comments DU0 22 891072 837824 94% 16 0 RSTS10 1.2 Pub, DLW

So this might be relevant. If the reported size is sufficiently different, things will break. For MSCP, RSTS cares about the device size (LBA count). It pays no attention to reported "geometry". It displays the reported device type string (in INIT "Hardware List" option) but it doesn't care about what those are. If a gigabyte disk claims it's an RX50 (or an RX98), RSTS will happily display that string without any objections. paul

A real RA81 has 891072 blocks, i.e., it's 445 MB. If your partitions are indeed 1/4th of a 2 GB disk they may be just over 512 MB. If so, your RA81 image is not valid for those partitions. Try shrinking the partitions to be the actual RA81 size, or slightly larger. By the way, another possible issue: the free space bitmap in file SATT.SYS is created at pack format time to be large enough for the number of clusters on the disk. If you move the image to a bigger disk, even one with the same device cluster size, it may be that the number of pack clusters now exceeds what SATT.SYS describes. That too is an invalid file system. I would expect that to give a more explicit error message, but it may be that this doesn't happen in INIT, or not at this stage. Either way, the short answer is: RSTS will object to file systems moved to a smaller destination, or to one that is too much larger. What is "too much" depends on a number of details. paul