Guy> I found that the best way to backup/restore is to use tape. I Guy> have a TU80 on the PDP and a SCSI 9-track on the PC. Works Guy> great and is much faster than the serial line. Ethernet is another good way; DECnet is available on Linux. paul

Zane> It helps that I have SCSI Controllers on my operational Zane> PDP-11's. I use removable disk trays that allow me to move the Zane> HD's between PDP-11's, and more importantly to hook them up to Zane> a Unix box, at which point I can use 'dd' to back them up. The Zane> resulting disk images can be accessed via SIMH, E11, or burned Zane> to a CD-R and accessed on the real PDP-11 HW. I've managed to Zane> boot and install RT-11, RSX-11M, and RSX-11M+ from CD-R. I've Zane> yet to figure out how to do that with RSTS/E. If the CD-R is on a controller RSTS understands (MSCP is the only option I can think of for this) and is formatted with the RSTS file structure, and has a boot block in sector zero, it should all just work. I haven't personally done this but I'm pretty sure it was done by one of my friends. I even have some weird "hybrid file system" hacks in RSTSFLX to let you create a CD-R that's partly ISO and partly RTST, and bootable. I believe that was used and shown to work, though I never saw the results. If you have the files, RSTSFLX can make a bootable disk image for you, so you can try this yourself. paul

Antonio> If you try hard enough, you can build a hybrid system where Antonio> the ODS-2 and ISO9660 sides have different trees but share Antonio> the same data (useful for stream-LF and binary files). Cool idea. I didn't do that -- didn't think of it, and also because I didn't know enough 9660 then. Antonio> I presume RSTS is ODS-1, which IIRC is ODS-2 but without a Antonio> few of the bells and whistles so the structure is quite Antonio> close to ODS-2. I would expect that you could interleave Antonio> ODS-1 and ISO9660 fairly easily. No, RSTS is RDS-1; it's a file structure all its own, totally unrelated to any other PDP-11 OS. (It's a distant relative of the TSS-8 file system, though.) In particular, the naming aspects (directory) and file block to disk block mapping aspects (file header in ODS, inode in Unix) are combined in the RSTS directory structure, unfortunately. So there is no rename across directories and neither softlinks nor hardlinks. It's all nicely documented in the RSTS internals manuals, and you can also read all about it in the RSTSFLX sources. paul

On Wed, 2005-06-22 20:55:32 +0100, Antonio Carlini <a.carlini at ntlworld.com> wrote: As for ODS-2, the vax-linux kernel does have some limited ODS-2 support. So if you've got some raw partition dumps, you may be able to to loop-mount it (or crash your box, depends on computer's mood, moon phase, jupiter's constellation towards earth and the answer to the final question...) MfG, JBG -- Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

I didn't have any problem with getting RSTS/E to start to boot off of CD-R, where I had problems was with it not liking the fact it was on a Read-Only filesystem. If I had a better understanding of RSTS/E, I suspect this could be overcome. I've not had the time to look further into the matter. Zane

Stan> Hi, Zane H. Healy said: Stan> I think RSTS/E writes or re-writes something during the boot Stan> process to check that it was properly shut down last time it Stan> was used. The quickest way to check would probably be to look Stan> at the code in SHUTUP.BAS You're thinking about the "cleanly dismounted" flag in the pack label. That's handled in the kernel, not in shutup.bas. In any case, that flag is written at mount, and again at dismount, but ONLY if the pack is a read-write pack and being mounted read-write. If you mount the pack read-only (via the command line option, for example) or the pack is marked as read-only in the pack label, then the "mounted" flag is NOT touched at any time. Read-only means what it says. If you mount a pack that way, RSTS will NOT write it, ever. That feature is used in a bunch of places; distribution media is one example. Those would normally be loaded with the hardware write-lock switch set, but whether ot not that is set, the software write-lock flag in the pack label will tell RSTS never to write to it. paul

Zane> .... I also typically Zane> have either a TZ30 (half-height SCSI TK50 drive), or a TLZ06 Zane> (4mm DAT) drive hooked up. I prefer to use DAT, however, Zane> RSTS/E software doesn't really like trying to be installed from Zane> DAT. Why, what happens? If it's TMSCP it should work. Some of the I/O won't be streaming I/O, since the RSTS install process doesn't switch to the BACKUP tool (which supports streaming) until partway through. So if your tape drive can't hack start/stop operating mode, then yes, that could be a problem. In that case, I'd argue it simply isn't a good drive at all. paul

Zane> As I understand it, the issue was with variable byte blocks. I Zane> had zero issues installing RSTS/E, and I think a couple layered Zane> products off of 4mm DAT. However, DECnet/E would not install Zane> off of DAT. You mean variable length blocks? If it doesn't support that, it isn't a proper tape. Proper tapes handle any block size, odd or even, from 14 up to at least 8k or so. paul

Zane> At 9:19 AM -0400 6/23/05, Paul Koning wrote: >> >> Zane> As I understand it, the issue was with variable byte blocks. I Zane> had zero issues installing RSTS/E, and I think a couple layered Zane> products off of 4mm DAT. However, DECnet/E would not install Zane> off of DAT. Zane> Yes, that's what I mean. It is my understanding from when I Zane> got some help figuring this out (I think by this list), that Zane> was the problem. It wouldn't install from DAT, but had zero Zane> issues with TK50. Ok. RSTS does assume/require that tapes are designed by competent designers. I'm surprised you didn't run into similar issues with other operating systems. paul

Jerome Fine replies: Since the most expensive part of a SCSI connection to a real DEC Qbus backplane with a PDP-11 is the SCSI Qbus host adapter, then if anyone already has one, I recommend a magneto optical (with removable media) disk drive. While 300 MBytes these days is very small, about 5 years ago, I purchased a number of Sony SMO S-501 magneto optical disk drives (when they were already 10 years old). I also have a good quantity of media - which since they are double-sided (but the drives can read ONLY one side at a time) actually hold 600 MBytes in total. And since the drives are much faster than both a TK50 and a TK70 (aside from also being random access), they are much better than both tapes. Since I don't know how fast a TLZ06 tape drive performs, I can't comment. As for a transfer between different systems, I find that the magneto optical is both fast enough and large enough for everything I can imagine using RT-11. The cost of a Sony SMO S-501 is small compared to a SCSI Qbus host adapter, so I usually have one on each system that uses the media. In addition, for RT-11, 300 MBytes (8 RT-11 partitions) is sufficient to provide backup capability. This dual use (transfer and backup) more than justifies the magneto optical media on a PDP-11 as far as I am concerned. One thing about a CDROM drive as opposed to a DVD drive on a PC is that the normal (IDE) CDROM drive was not able to read the first 64 blocks (16 CD sectors) of the CD under E11 using RT-11. My DVD drive on the PC does allow E11 under Windows 98 SE to read those first 64 blocks of the CD and I can BOOT RT-11 on the PC under E11. As a result, I do not have much of an incentive to acquire a CDROM drive that will work with my SCSI Qbus host adapter on the PDP-11. If ever anyone is discarding such a CDROM drive, please let me know. It would be "nice" to be able to boot from a CDROM drive on a real DEC PDP-11 system. Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.