On Thursday, May 26, 2016 at 1:37 PM, Paul Koning wrote: > > On May 26, 2016, at 4:34 PM, Quentin North <quen...@quentin.org.uk> > wrote: > > > > I wonder whether OP is referring to a situation where there is a 96 > > character > > line, such as a programming language statement, and that the first 80 > > characters would be on a card and then the remaining 16 characters would > > be on the next card but with a continuation character in, say, column 1. > > > Fortran and some other languages certainly had the notion of continuation > > cards, but then the statement length was pretty much unlimited, certainly a > > whole lot more than 96 characters. In any case, that has no bearing on the > > I/O device (real or emulated), cards still only deal with 80 character > > records.
I agree. If this whole discussion is about if a simulated card reader device interface should try to magically correct for garbage input (i.e. lines longer than card images), then I suggest that the best simulation is to behave as closely to how real systems worked. Specifically, they'd pass garbage input in (truncated to the card image size for the specific device) and you'd get garbage output. The user would have to puzzle out, just like they originally did if they typed what they thought was part of a Fortran statement past column 72. Automatically wrapping extra-long lines may or may not be the right thing to do VERY MUCH depending on the context of the data being wrapped. That said, it would certainly be completely reasonable for a simulated device to read and analyze all of the input is being asked to process when an input file is "ATTACH"ed. If problems in the data are observed, the attach could fail with appropriate diagnostic details being emitted. - Mark _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh