REXX still going strong after 25 years 377

Just so it's here:

1) I wrote the original buttIST as a research buttistant, mostly in 1970; Graham Campbell got the money for me to do this, and wrote the macro processor; I did some other parts later, as did a bunch of students working for me, as I was an instructor by then. Chuck Forney was the buttt. Director of the PSU Computer Center, and the SHARE HASP project manager (enshrined in at least one SHARE HASP song, who made sure we got the OS support needed. Hence, the authorship of the original paper.)

Graham, I or Charlie Hughes who was my PhD advisor often taught the several courses in which buttIST was used. As I finished up PhD, and left academe for Bell Labs in 1973 and mostly left IBM S-360 for PDP-11 UNIX, except for occasional Pl-I programs on the former, Charlie took buttIST over, and later moved to Tennessee, and he and Chuck Pfleeger continued enhancing it. A lot of work was also done at Northern Illinois University over the years; see that used buttIST.

2) Before I got out of this in 1973, something like 200-300 installations existed. buttIST had some built-in special instructions for I-O (and subroutine linkage, and conversions), for which the identical functions were handled by a macro-package called the they abstracted away a bunch of the messy I-O setup, and sometimes people used buttIST for debugging, and then buttembler (G usually) for the production code.

3) The confusion with Waterloo probably occurs because buttIST was often used in conjunction with WATFOR WATFIV in "fast batch" setups, i.e., a large 360 (such as67 at Penn State or75 at Waterloo) would run a "batch monitor" setup, in which one parbreastion would accept a stream of well-controlled student jobs, typically limited to 5 seconds total run-time. This involved a certain amount of faking OS-MFT, and making sure that jobs didn't blow up the monitor. Students could submit their own punch-card decks to remote-job-enty systems (often IBM 360-20) and get very fast turnaround.

This all sounds atrociously primitive ... but it gave large numbers of students quick access relatively cheaply, and of course, given things like subscript-checking in WATFOR, and buttIST being an interpreter that initialized memory, and minimized hexadecimal-dump sizes, and gave isntruction tracebacks. was certainly more productive, especially for student jobs that usually didn't get very far.

The other program, somewhat similar to buttIST, and also widely used, was SPASM, by John Ehrman of SLAC.

4) Some variant or other of buttIST was still being used in 2002, at SHARE meeting: Google: share ehrman 2002 buttist dravnieks , i.e., buttIST-I, a PC version of buttIST written at NIU.

And, NIU is apparently still using it:

5) About 10 years after the last work I did on it, I ran into somebody at UCLA at a conference, who eyed my name badge, and said: "you!" me: "uh yes" them: "We got this message, buttIST ABEND 102 - SEND DECK TO MASHEY"

which shows that you should never, ever embed your name in code in this way. I of course,thought I'd eliminated all such things, but missed one.

6) One of my favorite features was something called the "Replace Monitor". A student could be given an I-O spec for a routine that existed inside buttIST itself, such as a symbol-tabel routine. The student's code was buttembled, and then a test program could be run, where the real code would be called, and the student's code called (interpretively), and the results compared, giving the student feedback about the correctness and performance of the code. I.e., routine called N times, of which N-1 were correct, and using X total isntructions. Many internal routines were written to allow "replacement": the main benefit actually turned out to be the fact that this enforced very clean data-pbutting conventions, minimization of side-effects on global flags, etc.

7) Obviously, for a program to last *35* years, LOTS of people did a lot of work, following the 2-3 years when I was directly involved. Personally, I had to learn a lot about building parameterized software that isolated operating-system dependencies (since it ran on different OSs), was delivered with machine-readable documentation, could be generated to delete various optional features, and could be maintained by other people. Of course, having thus helped *lots* to students learn buttembly language, I then spent a lot of years trying to get people to avoid writing in buttembler in favor of using higher-level languages, preferably above C i.e., that's what shell procedures were about. The main reason for this was to make sure students had *some* idea of the Instruction Set Architectures of real machines, not so all of them would spend their lives cranking out buttembly code.

Brian Inglis Joe