🚀 go-pugleaf

On Saturday, August 11, 2018 at 5:30:04 PM UTC-4, Adam Sampson wrote:
> There's nothing like a good debugging war story -- go on, then!

Over at St. Potato's College (that's a different story, told here: https://www.glaver.org/blog/?p=926 ), we evolved into being DG's largest XBASIC customer. They probably got the hint when they got a STR from me that said "XBASIC SYSGEN allows any 32 terminals to be controlled by that XBASIC instance, as long as they're the first 32. We have 96 and would like to use the other 64."

They fixed that one, and a followup regarding interactions with our in-house-developed F2 and F3 partitions (this was on RDOS, which only provided BG and FG - background and foreground). They pretty much asked "what the heck are you people doing over there?" and I replied that we were running 96 XBASIC terminals, 32 in each of FG, F2, and F3 and that we had an in-house system (written by yours truly) running in BG that allowed any of the 96 BASIC terminals to edit jobs in other languages (DG supplied FORTRAN IV and something vaguely Algol-66-like which eventually morphed into DG/L - kind of the DG equivalent of DEC's BLISS - a system implementation language). We got Pascal and (IIRC) COBOL from somewhere else. I built a batch job scheduler that ran sequential jobs in the background and returned them to the submitting user. It was possible to SYSGEN XBASIC with custom user-written assembly language code, invoked by "Call <digit>" in a BASIC program. So the users had the ability to see where in the queue they were, kill a queued or running job of theirs if they discovered a problem, or flush the job from either the slow- or high-speed lineprinter queue if they had an output runaway. The operator could also use any of those requests against any job - for students they could only request them against their own jobs. Bear in mind, this was running on an Eclipse S/200 ('181 ALUs, like a PDP-11/34 or 11/44) with 256Kb of memory. It did have a separate comm chassis that I'd installed, so the com ports were a single DMA peripheral, not a bunch of individial interrupt-per-port cards. We had a 6061 192MB system drive (closest DEC equivalent would be an RP06) and an 8MB fixed-head drive that was normally used as the paging device on the higher-end AOS/VS systems. That was the subject of a different STR - "paging disk not considered bootable for RDOS residence", which was also fixed by DG with a grumble.

But, as Alro Guthrie once famously said, "That's not what I came here to tell you about".

DG XBASIC used a bunch of clever tricks to service up to 32 terminals from what the CPU considered a single process. It was internally threaded, riddled with coroutines with undocumented dependencies, and so on.

One thread was responsible for parsing human-readable programs into the internal representation that the interpreter used. There were similar threads for the reverse:

LOAD - read internal representation from disk into program memory
ENTER - read human representation from disk into program memory
SAVE - write internal representation from program memory to disk
LIST - write human representation from program memory to terminal or lineprinter
STORE - write human representation from program memory to disk

The culprits here are ENTER and STORE. A user had developed a massive application (serious research on eye movements called saccades) and needed to analyze the data on the computer. As I recall, it was some 40,000 lines long on a system that only allowed line numbers up to 9999.

Based on my familiarity with the system, I said that if he constructed his program as a series of separate overlays, all using the same series of line numbers (for example, 5000 through 6990 by 10's) he could STORE out that overlay and then activate it in his main program by saying '1000 ENTER "some-overlay-name"' where 1000 was a line number in the base (non-overlayed) part of the program. Enter performed a merge of whatever was in memory at the line numbers contained in the new code, so any new code would replace the old code of the same line number. As long as there was rigid compliance to line numbering (always being increments of 10, etc.) this worked quite well, the researcher went away to do other researcher-y stuff, and the student he sent over to do the grun work of processing the data easily got the hang of the system.

The next semester, this had proven so popular that there were TWO students running the data analysis program. The minute the second one would start using the program, both programs would fail will all sorts of bizarre errors - doing a "LIST" would show not only pieces of other overlays, but strings of gibberish, including control characters, pieces of other address space, etc. Pretty much like what happens in the movie "The Fly", but more gruesome.

After a bunch of local analysis, I decided that the single thread that processed
ENTER statements was getting confused if more than one terminal thread requested an ENTER at the same time.

DG eventually agreed, sent back my STR with the source tapes, and said "you're welcome to fix it if you want to". I looked at the code, which was very tightly written, probably by a single person, and was pretty impenetrable.

I suggested the program be modified to write data to intermediary files and use CHAIN to launch the next piece (former overlay). It was a lot less efficient, as it was common to flip overlays back and forth for each line since the overhead was so low.

That department insisted we keep that S/200 in operation for many, many years after it went out of support, since the did not want to move their application to either PDP-11 RSTS/E or VAX/VMS. I think it hung around until 1987 or so before I could no longer maintain it and it was donated.