[HECnet] Re: quick help on RSX FORTRAN problem?

On 2026-04-10 09:46, Paul Koning wrote: I definitely had disk block addressing go wonky* in a late V9.x release. Diagnostics detected a bad FPP and after I replaced it, RSTS/E (the OS and utilities part, not just user apps) was happy again. Did the change from CSPCOM to actual BP2 for CUSPs drag in some FP stuff? That shouldn't have affected the monitor, though. I'll need to go look in the FIP source code... * For other folks, RSTS/E goes out of its way to keep most file- system stuff in 16-bit ints or smaller. This does result in very large pack cluster sizes on "big" (for the time) disks like the RP07, to keep the total number of clusters below 65536**. Of course, when you talk about absolute disk blocks they exceed 16 bits pretty quickly. ** If I were ever going to do a RDS 2, these fields would all be made larger so that tiny files don't take up a whole 64 blocks. I wonder if that was added in anticipation of the PDP-11/74 (the CIS one, not the renamed 11/70MP). It certainly isn't much of a win over a processor move loop on an 11/23 or 11/24, and the only other PDP-11 that had CIS was the 11/44 (where it was pretty good, but nowhere the screamer the 11/74 was***). Or may- be DEC thought the J11 would still be available with CIS. In- stead the J11 limped out the door without ever meeting its 20MHz clock goal, and was the subject of multiple recalls (along with its FPA, and PMI memory that corrupted memory contents during some block mode DMA operations). *** The 11/44's CIS chomps through data 16 bits at a time inter- nally. The KE74 (11/70 CIS) chomped more bits at a time and also had a completely separate packed/zoned decimal datapath that also handled the character move instructions and also prefetched characters directly via the 32-bit memory bus. It was a minimum of 5x the 11/44's KE44 and could run up to 10x faster for some operations. This is per someone who developed the microcode and ran it on actual boards - things had gotten to the point that the boards were assigned M-numbers (2x M8165 control store, 1 x M8166-M8168) and a Field Maintenance Print Set was created. Then the project was killed due to it wildly outperforming the VAX-11/780 on industry-standard COBOL benchmarks. Since "VAX was the future", the KB11-E 11/74 never saw the light of day. Then the 11/70MP project (multiprocessor 11/70) took over the 11/74 name (which is why extant photographs show a mishmash of 11/74 and 11/70MP on the front panels and cabinetry). That one was cancelled due to maintenance complexity as well as every order needing to be sent to the engineering team (not just the project management) for configuration validation. Those two different stories got combined by rumor and hearsay into one single reason DEC cancelled the 11/70 improvements, although they were two separate projects with separate reasons for can- cellation.