4 ms·

Is there a URL that talks more about how CICS pulled that off?

tyingq 7y ago
3270 terminals are block mode, so there's less state for the server side to deal with as compared to a typical Unix terminal. I'm sure there's more clever stuff, but that does help a lot.
- PaulHoule 7y ago
  It's actually not that different from a traditional (pre-AJAX) HTML forms web app. That is the mainframe would send out a burst of data to draw a screen on the terminal, the user would fill out the fields, then the user would hit a button that sent the field content back to the mainframe. Thus the mainframe did not so have to handle an interrupt for each character but instead just one for the whole form.
  - drudru11 7y ago
    Ah. Thanks guys.
    - PaulHoule 7y ago
      I'll fill in some more things. They didn't have the bloat back then that we have these days, like the crazy deep call stacks you see in both object-oriented and functional programming. CICS programs were frequently written in assembler, sometimes COBOL and PL/I. Mainframe compilers from the early 1970s were much more advanced in many ways than the Unix/C technology described in the Dragon Book. The mainframe did I/O through channel processors which were quite expensive in themselves, but offloaded a lot of work. CICS did many things that operating systems do in user space. IBM never did produce a "ring to rule them all" operating system for the 360 series, but with the 370 some academics figured out how to run multiple operating systems in virtual machines. So CICS could run in a VM with the minimal OS that it needed. Mainframe systems had the source code for CICS and the OS and usually used a custom build, so the kernel didn't have anything it didn't need. The machine was expensive but cost effective if you used it efficiently, so people did.
      - drudru11 7y ago
        Thanks for elaborating more. I think people who do performance work constantly rediscover or re-invent this (ie like the websocket post).

3270 terminals are block mode, so there's less state for the server side to deal with as compared to a typical Unix terminal. I'm sure there's more clever stuff, but that does help a lot.

PaulHoule 7y ago
It's actually not that different from a traditional (pre-AJAX) HTML forms web app. That is the mainframe would send out a burst of data to draw a screen on the terminal, the user would fill out the fields, then the user would hit a button that sent the field content back to the mainframe. Thus the mainframe did not so have to handle an interrupt for each character but instead just one for the whole form.
- drudru11 7y ago
  Ah. Thanks guys.
  - PaulHoule 7y ago
    I'll fill in some more things. They didn't have the bloat back then that we have these days, like the crazy deep call stacks you see in both object-oriented and functional programming. CICS programs were frequently written in assembler, sometimes COBOL and PL/I. Mainframe compilers from the early 1970s were much more advanced in many ways than the Unix/C technology described in the Dragon Book. The mainframe did I/O through channel processors which were quite expensive in themselves, but offloaded a lot of work. CICS did many things that operating systems do in user space. IBM never did produce a "ring to rule them all" operating system for the 360 series, but with the 370 some academics figured out how to run multiple operating systems in virtual machines. So CICS could run in a VM with the minimal OS that it needed. Mainframe systems had the source code for CICS and the OS and usually used a custom build, so the kernel didn't have anything it didn't need. The machine was expensive but cost effective if you used it efficiently, so people did.
    - drudru11 7y ago
      Thanks for elaborating more. I think people who do performance work constantly rediscover or re-invent this (ie like the websocket post).