4 ms·
I've been faffing about with mainframe stuff lately using Hercules. So I'm going to nominate ISPF on mainframes. https://en.wikipedia.org/wiki/ISPF https://en.
by bitwize 3y ago
I've been faffing about with mainframe stuff lately using Hercules. So I'm going to nominate ISPF on mainframes.
https://en.wikipedia.org/wiki/ISPF https://en.wikipedia.org/wiki/ISPF
Because the IBM mainframe world was late to the time-sharing party (ISPF was based on TSO, the Time-Sharing Option for System/360 and System/370, because the default mode for mainframes was batch processing from punched cards), and because IBM's 3270 terminal used screen-at-a-time updates instead of character-at-a-time, sending interrupts to the CPU only when Enter or a PF key was pressed, ISPF feels clunky and foreign compared to modern TUIs. But it really had a nice design, providing a vast improvement in UI to the mainframe in the form of a menu-driven interface, with a common API that application developers can use to take advantage of the same interface features as the system provides. There are even comprehensive help screens. Here's a demo of ISPF in action:
https://www.youtube.com/watch?v=IWVD2yM3tsY https://www.youtube.com/watch?v=IWVD2yM3tsY
This interface, or something like it, is what my mom used during her early days as a customer service rep for a large insurance company back in the 90s. You tab between fields, mash Enter to send the whole form, or hit an F key to take various actions. She became quick and efficient at entering or updating customer data. Then they switched to an all-new, all-shiny J2EE app with a browser front end, and she was completely at sixes and sevens. She may as well have turned into a large insect like Gregor Samsa, because the new UI made her less productive, she was punished for it, and she was not allowed to train with the new UI.
We think of mainframes as old and stodgy, but really what they were built to do they were great at: accepting and processing large amounts of business data and transactions. The workflow for that use case was incredibly streamlined, and modern software businesses could learn a lot from how the mainframe did things.
- morsch 3y agoNot sure how related it is, but I found this series on the AS/400 fascinating: https://youtube.com/playlist?list=PL9tkJGALYJ6CzZSPwM-09E5tkfvBn3KR5 https://youtube.com/playlist?list=PL9tkJGALYJ6CzZSPwM-09E5tk...
- bitwize 3y agoThe AS/400 (aka IBM i) appears to be of a different lineage, derived from the late-70s IBM System/38 minicomputers. Nevertheless, it sports many IBM-isms in its design, including integrating database functionality directly into the operating system, making database tables and files almost coterminous with record-level file access being the primary mode of access; and the use of block-oriented, rather than character-oriented terminals (the IBM 5250). Interestingly unique to IBM i among IBM operating systems is the pervasive use of object orientation throughout its system APIs; there are no pointers, everything is an object over which some operations are permitted and others forbidden. While the mainframe series retained darn-near-perfect backwards compatibility through system-level emulation of old architectures on top of new architectures, IBM i's solution to this problem is different: TIMI (Technology Independent Machine Interface), a kernel-level abstract machine to which all IBM i applications are targeted. No programmer access to the underlying machine code is provided. Rather, the first time the kernel loads a TIMI executable, it AOT-compiles it to whatever the underlying CPU architecture it is. This enables seamless CPU architecture changes with perfect backwards compatibility for application code; this already happened in the 90s as the AS/400 line migrated from a System/38-based architecture to PowerPC.
- js8 3y agoCompared to ISPF, some people also loved XEDIT or Roscoe for their ability to integrate adhoc scripting with TUI.