Lit. Buffer overruns 1690

when i was an undergraduate, one of the changes i made to cp67 (besides adding a whole slew of performance enhancements) was to add tty-ascii support.

standard os-360 & dos was everything (including specifying all i-o devices) needed to be defined in sysgen ... although they tried to alleviate that later in 370 timeframe by introducing "E4" extended sense channel command code ... which would ask the device what it was (only new hardware got the "E4", so there still have to be sysgen for the pre-existing 360 timeframe devices that might still be in use).

cp67 for at least the terminal support had tried to automatically detect whether it was talking to a 1052 or a 2741 one a line (and what kind of 2741). the standard telecommunications control unit, 2702 had "SAD" comments that could dynamically buttociate a line-scanner with a specific line ... i.e. the standard cp67 support set the line-scanner to a specific type and tried some commands (that were known to fail on the wrong device) and then reset the line-scanner and tried some more commands.

so I thot I would be devilish clever and do similar scenario when adding the support for tty-ascii. I got it all tested and it appeared to work fine ... until the ibm field engineer informed me that I was just being lucky during my testing. part of the objective was to be able to have a common dail-up pool with single phone number for all terminals. my testing had so far been limited to fixed connected lines ... but i hadn't yet tried all three kinds of terminal dialing into the same phone number. The problem was that they took a short-cut in the 2702, while they provided the ability to buttociate any available line-scanner with any available line ... they had took a short-cut and hard-wired the oscillators to specific lines ... aka you would have problems trying to connect a 2741 (134.x baud) on a line with a oscillator hard-wired for tty (110 baud). The code would correctly recognize any terminal on any (fixed) line w-o sysgen specification ... but the hardware limitation wouldn't allow dynamic line speed operation.

So that was one of the things tha prompted the university to build our own plug-compatible telecommunication controller ... the line-scanner was implemented in software on the interdata-3 and would strobe the raise-lower of the incoming signal to dynamically determine the line-speed. Originally a single interdata-3 handled both the mainframe channel interface as well as all the line-scanner-port interfaces. This was later expanded to a cluster of machines with a Interdata-4 dedicated to handling the mainframe channel interfaces and multiple interdata-3s handling line-scanner duty.

misc. past 360 plug compatible controller posts:

and to not stray too far from the buffer overrun problem ... this is a rare example i know of in cp67 that exhibited the problem. because of tty-ascii spec, i had used one-byte arithmatic in calculating lengths. The way I remember the event, I think it was called the MIT Urban Lab ... in tech sq ... but a building across the courtyard from 545 (565? ... harvard trust was on street side of the first floor) ... CP67 was modified to handle some sort of graphics-plotter(?) ascii device at harvard(?) that had line limit more on the order of 1200 characters. The max. length fields were correctly modified ... but the use of one-byte arithmatic wasn't changed ... and so there was 27 cp67 system failures one day. tale of the tragedy appears here:

--