P390 playing with DOS, Pertec power supply diagnosis and repair work

P390 SYSTEM CHECKOUT

When I left off testing, I had formatted the DOS pack using the standalone ICKDSF utility, settting it as a minidisk, but then the DOS standalone restore utility quit with a complaint about the disk. I could download and read the source code for these utilities - once I figure out which of nine optional materials tape images contain the code.

I would have to bring up an existing DOS image in order to run the restore of the tape, so there is some work I need just to do this. It turns out that if there is a premade DOS image I can bring up under VM, it would let me do a restore of the DOS pack I wanted without needing the standalone utilities. That is, I could run the restore utility in a premade DOS image, using it to restore the contents of the tape to my target DOS pack. Then, I would have DOS ready to IPL to continue my ground-up install of DOS.

In the interim, I pulled down a slightly out of data version of the DOS/VS Messages manual to see exactly what it listed as the reason for my message to be issued. That didn't help, but buried in the sysgen manual is one small phrase in a sidebar - the restore program ignores what device type you specify and instead determines it by reading the Format 4 DSCB from the disk volume.

Aha! This is back to the same old problem that I can't get the standalone initialization program to work. My workaround using ICKDFS to do a DOSVTOC as it calls it obviously omitted setting the critical device type data in the Format 4 DSCB. Vexation!

I gave a try to build a virtual 3350 that is 560 cylinders, thus containing the space that will be used by the DOS initialization program to format the alternate tracks. I was  hoping that the configuration program for the P390 wouldn't impose a 555 cylinder limit on 3350 disk types. Fortunately, it didn't.

The initialization program ran perfectly, as did the restore job. Doh! At least I have the system ready to begin my system generation steps. It may have taken a few extra days to get going, but I am pleased that I am now moving forward.

What I need to do is IPL the newly restored pack, do some special one time commands at IPL and right afterwards, then the install is done. The IPL and 'enter' on the virtual console gives me the first IPL message requesting the supervisor to load. The distribution tape comes with several IBM supplied supervisors with various features and device configurations.

However, the details on those supervisors is in attachment 2 to the cover letter, but whoever saved the DOS VS 34 cover letter omitted the attachments! I don't know anything about the supervisors $$A$SUP0 to $$A$SUP5 which is a problem.

I can overcome the device address issues by using the IPL time commands DEL and ADD which let me manipulate the devices at various addresses. However, some details in the supervisor may be required to run - e.g. it may need to have been assembled with 3350 device support. Yet, I can't tell what the supervisors contain since I have no documentation.

Once the supervisor name is entered, the P390 sits in a loop, running forever and ignoring the enter on the console that would allow me to start issuing ADD, DEL and other commands. Hmmm. This will take more research. For example, is the supervisor attempting to use 2K storage protect keys, which are a no-no on the P390? Is it lack of 3350 support? Is there some other issue causing the supervisor to fail or loop?

PERTEC D3422 DRIVE RESTORATION

The darned crowbar protective circuit is forcing the fuse to blow so fast I can't sort out what is wrong in the power itself. I suspect a diode is bad but it is hard to test everything in circuit due to the interaction with other components.

I see a way to use my lab power supply to inject +10 and -10 to the circuit in order to see how the +5V and -5V regulators deal with that. The good news, with the two external heatsinks disconnected, I got the right reference voltages to the op amps. I removed all the crowbar scrs and began shooting the issue.

With the heat sinks connected (power transistors producing the regulated +10, -10 and +5 supplies), I still get a fuse popping in the -20V raw supply. The +10V level is fine, but the -10V drops to about 1 V because its =20V input supply fuse is blown. I didn't attempt to look at the +5 level, because with the fuse blown, all bets are off.

I decided I should follow the raw -20V line a bit, since it is fed to other circuits that don't need regulated power. I found that the line goes to several places on the servo board, which all have to be checked for defective parts or shorts, as that could be where my problem is arising.

I was hoping to find that most of this went off-board and was therefore isolated since I had most cables disconnected, but alas I see enough connections and components on this board that I know this will be a slow, time consuming search.

I cleaned things up so that if I supply only the -20V raw power (not the +10 and +20), I get good regulated voltages of -10V. If I supply the +20V raw only, I seem to get the right +10V output. Something goes awry when all three raw voltages are present. I see one of the fuses blow but before it happens there is a period where I can verify that both +5 and -5 outputs are good.