5

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?

Improve this question
2
  • 3
    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, 2020 at 21:04
  • 1
    When I was in Uni, our lecturer told us that the ICL CARD-READER actually read a file. He called it a CARD-FILE because the file was created from input cards. Nobody had worked in industry before and we didn't know any better and nobody questioned him about it.
    – cup
    Jun 27, 2021 at 7:51

2 Answers 2

Reset to default
7

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' (*2) 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 (*3), 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 mane 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 use cases for an additional hole or two :) (*4)

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 - in the early days of computerization next to every manufacturer had their own extensions to basic punch card encoding. While numbers, signs and letters were set, everything past that was up for grabs.

In addition, customers as well nudged card use for their purpose. Need a way to encode the department in a single column? Just make up a combination not used so far!

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

*4 - In fact, this wasn't restricted to punch cards. In the mid 1980s (!) I met a blind lady using ED under CP/M to manage all her office data. Operating with a braile line ED was a perfect tool, and she was rather creative to use this in a way reminding of punch card computing. With the keypad she had, every 8 bit input could be created, so she invented combinations for common items like field names or abbreviations for Mr/Ms/etc. She had to memorizse to key combinations for letters anyway, so that were just additional letters to her. In contrast, her secretary had to learn that some Polish Ł meant Mr. while a Spanish ñ symbolized Ms. :)

Improve this answer
7
  • 4
    That seems like a plausible explanation of the meaning of 'direct' in this context.
    – another-dave
    Aug 31, 2020 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, 2020 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, 2020 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, 2020 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, 2020 at 18:35
3

Could possibly (also) have meant control of the card reader.

Some card readers had multiple output bins and you could read a card, do a short computation, and then programmatically select which bin to put the card just read into.

This was used mostly for kicking out error or exceptional cases (e.g., some payroll record that had a ridiculous hourly rate, or a negative amount on an invoice) and (if the reader had enough bins) you could use it for external multi-pass sorting.

I used a reader that had this capability on an IBM 1620. This page at IBM's "history" site shows such a card reader - if you click to enlarge the picture you'll see it - the big box on the left.

Improve this answer
9
  • 2
    Another plausible answer. The common idea here is low-level control of the card reader hardware. As Raffzahn correctly points out, that wouldn't be portable, and thus likely rejected by a standards committee.
    – DrSheldon
    Jun 25, 2021 at 15:12
  • 1
    My memory might be a bit faint, but I'm pretty sure that is something never controlled by any HLL with abstract I/O. Selection of bins had to be done within a certain time. To do so the program must be in charge of the low level I/O to handle the device before the card ends up in the remainder (last) bin. Also, these functions were AFAIR all controlled out of band.
    – Raffzahn
    Jun 25, 2021 at 19:02
  • 2
    @Raffzahn - yeah, 1620 had no interrupts - no polling either if I remember correctly - you did an I/O operation and then the machine waited for it to complete. At least I am definitely sure that the slow-as-molasses console typewriter operated that way ...
    – davidbak
    Jun 25, 2021 at 21:28
  • 2
    @Raffzahn - I get what you mean. The only reason I suggested Honeywell might have done things like this is because I'm thinking of the 800 - with 8 hardware threads! (Quite an amazing thing for its time ...)
    – davidbak
    Jun 25, 2021 at 23:09
  • 2
    @Raffzahn - your comments remind me of Fred Brooks explaining in Mythical Man Month how they gave programmers for OS/360 a memory budget but no disk I/O budget - with the result that absolutely everything used overlays to disk and the first (internal) versions swapped themselves to death ...
    – davidbak
    Jun 25, 2021 at 23:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .