4

COBOL was the first exercise in design of a programming language by a committee of representatives from competing companies. irrespective of one's opinion of the technical quality of the end result, there is no doubt that it was highly successful from both an organizational and subsequent commercial perspective.

History of Programming Languages page 211 quotes one dissenting view from the Minneapolis-Honeywell representative, objecting that the specification the committee had produced, was deficient in four ways. Some of those are understandable, e.g. lack of a built-in sort capability (they were under time pressure; you have to draw the line somewhere).

But I'm confused about "the inability to process card input files directly". What, exactly, makes COBOL, even the first version thereof, unable to process card input files directly? I thought 'read a file of records e.g. from punched cards' was not only possible but extremely common operation in COBOL. Does the word 'directly' have a significance that I am not grasping? Is the dissenter talking about e.g. direct access to I/O registers for the card reader? Is the complaint that COBOL still needs support from some assembly language systems code for low-level I/O?

  • 2
    I was confused by that too. The only COBOL reference I have here, a thin 1974 university manual and therefore likely oriented to ICL 1900 implementations, has examples that show CARD-READER as a valid name in a SELECT...ASSIGN statement. We'll need to track down the original report, though. – another-dave Aug 31 at 21:04
5

Processing card input is among the most basic functions COBOL had to provide to get a hold in data processing - computers were meant to be integrated and improve existing card procedures.

Now, reading past the citation gives Ms. Sammet's impression:

enter image description here

I would think that the use of 'inappropriate' does indicate that the mentioned 'direct processing' of card input is something quite out of the intended scope of COBOL.

COBOL is all about machine independent processing of (decimal) integer and text. The later mostly by moving and comparing. To comply with this important goal, the language itself does not define a specific character set to be used, nor does it provide any way of binary manipulation of characters. All input or output was always thought to be opaque characters - not to mention, that back then most, at the time, were printable anyway - the number of non printable characters was, at the time, essentially zero.

With this in mind, the request of 'direct processing of card files' could refer to being able to read cards as image (aka the holes), instead of characters (*1). It's obvious that this feature could be useful to read 'foreign' data - while at the same time may introduce many possible ways to break code and programs, making them quite machine dependent. It is easy to see why this proposal might have received a lot of flak.

This interpretation gets some support when looking at the way how FACT (*2), Honeywell's business language, defined fields in terms of a mode specifier that included lots of punch card based definitions, leaving a lot of machine specific interpretation.

enter image description here

More so the input definition allowed not only the dame types for each column/field, but enabled definition of quite complex relations including redefinition of characters. For someone familiar with the way punch cards were used before computers and during early computerization, this may come extreme handy to read and process 'unusual' cards - like all the variant combinations users had make up for their specific purpose ... never underestimate the creativity of a user to find additional uuse cases :)

Just a guess considering the time, history and general workings in the punch card age.


*1 - Optional even the ability to manipulate these data (on 'hole' level) and output arbitrary images again.

*2 - IMHO COBOL inherited way more from FACT than from any other language including the often praised FLOWMATIC.

| improve this answer | |
  • 3
    That seems like a plausible explanation of the meaning of 'direct' in this context. – another-dave Aug 31 at 22:24
  • 1
    The ICL 1900 COBOL treated card input (and output) equally with paper-tape (8-track with parity). The paper-tape was ASCII, which included the unprintable control characters, and we used full ASCII to attach VT-7181 video terminals via multidrop RS232 for user data entry. However, I believe the card encoding could only use 64 distinct punch codes (it had 6-bit chars internally), from the 4096 possible encodings in the 12 rows. The 7-bit ASCII was handled through Alpha, Beta and Delta shift prefixes, to specify Upper, Lower and Control modes. – Paul_Pedant Sep 1 at 9:35
  • 1
    If I recall, the "decimal" punch exists in Cobol, and allows an N-character field to accommodate a signed N-digit decimal number, by translating characters J through R into -1 through -9, respectively. The mapping may seem weird, except that overpunching a minus sign on the digits 1-9 would yield J-R. – supercat Sep 1 at 9:56
  • 2
    Fascinating reminder of how much things have changed: These days, nobody would seriously propose a language feature for reading binary data from cards or, for anything else so specialized. We'd do it all through shared libraries and/or device drivers, and a standard API. – Solomon Slow Sep 1 at 14:35
  • 1
    @SolomonSlow: On the flip side, the failure of the C Standard Library to offer any guidance about how to handle non-buffered console I/O has resulted in a long-standing split between two approaches which could have been unified by requiring that applications both call a function before using non-buffered I/O, but then use separate function instead of getchar to directly read bytes from the console. Systems using the getch() approach could treat the first function as a no-op, and Unix systems could treat getch() and getchar() as synonyms, but code could easily be written... – supercat Sep 1 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.