Choosing a Programming Language

[Mike Novack]

Required recompiling.

We did not use assembler when we didn't have to as maintenance then limited to just a couple of us. Only when we had to for services not available to the higher level language. If we had expected frequent need to change the size I would have written the routine in assembler (which does support dynamic memory allocation).

OK -- since this has people curious, no, this was the reverse of having programmers code exceptions.

In a large system (about a half million lines, about 350 sub porgams, 90% COBOL) about 20 of the programs had had hard coding for cases that were exceptions to their processing. The volume of changes to the exxcption cases meant that 2-3 programs were being changed each week and that's a lot of programmer time considering the security involved in the process (a few minutes tot make the change itself, a few hours to get any change into the week's build).

Replaced with a single look up routine that each of thses programs could call to answer the question "is this case one of my exceptions". So now the exceptions are records in a data file. The first time the look up program gets called it sees the table is not built so reads in the file and builds the table before returning the answer. Subsequent calls of that night's run just do the look up.

The comment I was talking about was in case the number of exception ever grew larger than the available number of cells. This was telling the standby programmer what to do if called in the middle of the night becasue the look up routine aborted file maintenance with a "I don't have enough room" message. Not worth writing the program in assembler just to avoid this possibility that might not happen for years if ever.

I suspect that most of you are unfamiliar with batch runs so large you can't afford to do I/O for look up? (I'm just fallstalling that question -- no, several hundred thousand direct access I/Os not an acceptable solution!)

[RBerenguel]

I suspect that most of you are unfamiliar with batch runs so large you can't afford to do I/O for look up? (I'm just fallstalling that question -- no, several hundred thousand direct access I/Os not an acceptable solution!)

Well, I/O for lookup is a speed (and disk wear ) problem. I've done my share of clogging our department's computers with I/O (for some fractal computations with a huge amount of stuff done per pixel), and indeed, this is something you just can't let happen. In my case I just stopped writing data that was likely not needed and wrote as it was computed instead of every 1GB (sending 1GB to the disk every 20 or 30 minutes was worse for the system than sending it as it was computed)