Update tips

[stevefalco]

I have successfully added more disk drives on my PiDP-10. I followed the tips.2 documentation for that, and I have documented the additional information needed in tips.3.

This PR removes the old tips.2 file and replaces it with the new tips.3 file.

[eswenson1]

Looks great! Thanks much for doing this.

[stevefalco]

@larsbrinkhoff - I wound up with an unbootable system, and when I tried L$0$ I got an error that the file was no found, even though it looked like simh had all the disks. I don't know why that happened, and I agree that there should have been a way to recover, but I couldn't find one. That is why I added the warning.

I think the warning does no harm, but if you feel strongly, I'll remove it and push again.

[stevefalco]

I think dmpcpy did move the file on me. When I first generated ITS, DSKDMP showed that @ nits was on pack 2, as it should be, but once ITS started running it got moved to pack 4. At the time I tried using the L$n$ commands, and I could add all the drives except for 0. Finally, in desperation, I started from scratch (several times, actually) and moved the file while ITS was initially running. That's why I put in the warning.

I don't have the time right now to attempt to recreate the problem and hunt for other solutions.

[eswenson1]

I have not experienced DMPCPY moving files in the “.” Directory from one pack to another. @larsbrinkhoff have you looked at DMPCPY to see if there is any case where it might do this?

I thought DMPCPY only copied files out of the swap partition and only messed with some directories (like CRASH). I didn’t think it did anything in the “.” directory.

[eswenson1]

@stevefalco Are you sure you had the ITS image on the right drive from the start? On KL and KS, pack 0 = disk 0. But on KA, for some reason pack 2 is disk 0 (or vice versa). I believe PK0: and DSK0: devices are not the same on KA, but are the same on KS and KL.

@larsbrinkhoff probably knows for sure.

[eswenson1]

Well, I briefly looked at DMPCPY on my phone and see that it does process files in “.”, as well as CRASH and CRASH2.

But I don’t really understand what it is doing so will have to look when I get back to a real computer.

[larsbrinkhoff]

@stevefalco, L$0$ isn't the right command. It's not the drive or DSK number, but the pack number. So e.g. L$2$ would be DSK0. This is more FYI, you don't have to update the text.

@eswenson1, I don't remember exactly about DMPCPY. I have been getting .; ITS BIN moving between packs automagically for a long time. Some time ago I looked into it and arrived at DMPCPY as the culprit. But I no longer remember how or why.

[eswenson1]

@larsbrinkhoff Still looking at DMPCPY on my phone. I don’t understand it. Is it trying to find files that were written, say with DSKDMP or NTS DDT (such as when you load up an image with DSKDMP with L$, T$, and write it out with D$, where such files don’t have file dates, and copy them back to the same directory, in TS, such they get “normal” UFD entries?

if that is what it is doing, then I can see how, if @stevefalco created an ITS bootable image (@ ITS) using DSKDMP (or DDT in KL), it might change disk packs with DMPCPY.

I’ve not seen this happen recently because I always use ITS (TS) to create files in “.”. I don’t do this with NTS DSKDMP or DDT.

Please confirm, @larsbrinkhoff, how DMPCPY chooses files to copy.

[eswenson1]

Also, @larsbrinkhoff, can you explain the weird disk/pack numbering for KA? And why it is more sensible in KS and KL? Specifically, why is disk 0 not pack 0 on KA.

[eswenson1]

Fínally, @larsbrinkhoff, would you explain the “swapping area” thing to me (and others)? How does a file get stored there? Is it only when it is written out of timesharing (eg with DSKDMP or NTS DDT)?

Or are there other times when files get written there? And if so, why?

What else is the swapping area used for? I had assumed that it was used to hold memory contents when moving from NTS DSKDMP to TS (ITS) and vice versa. But I’m realizing I really don’t understand ITS notion of “swapping area”.

[larsbrinkhoff]

@eswenson1, I don't know about DMPCPY. Now that I check, it seems it's looking for files without a timestamp, and then makes a copy. I don't know why it does this. The title claims it gets data from the swap area. Maybe it does this in addition to the timestamp check.

The pack numbering is due to bootstrapping from ML ITS, which has disk 0-1 as packs 2-3. There's some inconvenience due to this, but also it highlights the disk/drive/pack distinction so I think there's a benefit.

I don't really know about the swapping area. I'm vaguely assuming "something" can write core dump to this area. And then there's a need to get the data out of there and into a regular file. But I haven't checked if this is true, or what does the reading and writing.

[stevefalco]

@stevefalco Are you sure you had the ITS image on the right drive from the start? On KL and KS, pack 0 = disk 0. But on KA, for some reason pack 2 is disk 0 (or vice versa). I believe PK0: and DSK0: devices are not the same on KA, but are the same on KS and KL.

@larsbrinkhoff probably knows for sure.

When I first ran DSKDMP on the new system, ITS was on pack 2, and DSKDMP had no problem loading and running ITS. However, once I was in ITS, it was on pack 4.

[eswenson1]

I’m pretty sure y’all were right about DMPCPY being the culprit for @stevefalco’s issue. When you save a file in DSKDMP or Exec DDT, it doesn’t get a file date. The most likely places where such files would be created are “.” and CRASH. Creating load able images with DSKDMP or DDT (for KL) normally results in files in “.”. And saving ITS (crashed) core images normally go into CRASH.

DMPCPY looks on those places (and in CRASH2) for files without dates set. It copies them to a temp file in the same directory without regard for disk/pack specification. ITS will choose a disk using its normal algorithm. This will oftentimes result in a different disk/pack than the original. It deletes the original and renames the copy to the same FN1 and FN2.

One could modify DMPCPY to use the same disk device as the original undated file, although now that we know the issue, it is easy to fix after the fact (and DSKDMP L$ command can mount any pack that DMPCPY copied the image to).

But if you want to guarantee that images in “.” stay where you put them, don’t use DSKDMP (except in emergencies) to create files. Use DDT in time sharing. I don’t see the described problem because I always create my ITS, (N)SALV, etc under time sharing. ITS DDT is more intuitive and forgiving anyway.