So here's the entry from May 12, 1986, I took the liberty of spelling out a few things that would have been in an odd shorthand:
Building 8 Raised Floor 4361-5 / 8 Meg
(let Eric know when finished w/4361-5)
1. Change uCode and IML
2. Restore System VMSRES --> 240 VMPK01 --> 241
VME R2 w/Fortran VMPK02 --> 330 VMPK03 --> 331
3. RUNFOP FSMIXFOP 20 20 1 182
061158-065658 Looks Good
4. Install Read Chain modules, Regen CMS & CP
5. RUNFOP FSMIXFOP 20 20 1 182
075653-084153 sleepers
6. RUNFOP FSMIXFOP 20 20 1 182
092419-100919 sleepers
This was a good memory for me. As I got a chance to help evaluate some new algorithms on chaining of reads. We might as well go right through this. Building 8 was one of the Glendale Lab buildings. The processor had 8 megabytes of real memory, and was one of the larger configurations at the time. I believe in that time frame, we did benchmarks with the minimum memory requirement of 768KB.
Doing performance runs usually involved dedicated hardware and that meant getting machine shots. In those days, we submitted requests like the week before and someone built a schedule for the following week. This meant planning was important, and there were often deals being made or people looking for spare time. So the second line was a reminder that I was to let Eric know that the machine was free when I finished my run. I don't recall if I had borrowed time from him or he was looking for spare time. Yes, this is the same Eric that would later be my manager.
Step 1 involved changing the microcode. That particular raised floor was shared with Glendale Engineering Processor Lab. Those guys would play with all sorts of things. So to avoid a surprise, we'd often put our own microcode disks in and re-IML (initial machine load or initial microcode load). I remember those were big floppy disks, maybe 8", I'm not sure.
Disk was also at a premium, so we'd often have to restore systems. That's what I was doing in my step 2. What I'd be doing is first a base measurement and then install the new prototype and do a couple measurements. Then we compare the differences. The "RUNFOP" was an exec that did the setup and ran a workload using a tool called FSID (Full Screen Internal Driver). It was a cool tool. It was modifications to CP that allowed it to create simulated virtual machines with hooks in modules like DMKGRF. I believe Galen Miller was the originator. There would later be VM/XA and VM/ESA versions of FSID. For many years, I owned the VM/ESA version. It helped me learn a fair amount about the system as it required mods to 3270 handling as well as the dispatcher and scheduler.
The parameters meant we'd run 20 userids simulating a CMS workload. So 20 userids in 8MB. The "sleepers" comment was that occasionally some of the simulated userids got out of sync and appeared to sleep or hang for some period of time. It could also mean that there was a problem with the system or the script of commands being executed.
The other thing I noticed from the notes is that the "061158-065658" were timestamps of the measurement. For me to have the measurement period start at 06:11, meant I must have gotten up pretty early. Just the price of working on a great system. :-)
No comments:
Post a Comment