For most of their history, IBM mainframes were used for two tasks: batch workloads and interactive users.
Batch workloads were things like billing: you're a utility and you need to do the accounting and billing for the million customers you have. You're MCI and you've spent a year advertising Friends and Family discounts and now need to do custom billing every month that figures out all those intersections of friends & family and sends custom billing. Not rocket science, just a lot of boring data crunching you have to do over and over again.
Interactive was everything you do today on personal systems: stores had terminal displays that hooked to mainframes for inventory control so salespeople could put together an order or cash registers would transmit sales near real time to a central mainframe and pump into/out of your ERP system.
Depending on your company's view of the mainframe world, you might have an MVS system doing all of the batch processing and a VM/TSO system providing interactive. And the MVS system could run under the VM system as a guest O/S, or you could partition the single mainframe to have MVS running on some CECs and VM running on others (e.g. you might have more interactive users during the daytime, then tune down the systems so that the MVS systems had more capacity overnight for batch operations).
Mainframes systems could be clustered together in a single data center and you could move workloads back and forth across systems while the workload was in progress. Eventually (circa 1994) you could link mainframe complexes together across DCs to provide redundancy (if a failure occurred in the mainframe equivalent of an AWS AZ the workload could, theoretically, transfer to another AZ with minimal interruption or reconfiguration).
On the interactive side…you could have thousands of systems connected to a single mainframe via various forms of I/O systems. All of your retail stores, all of the printers at those stores, frequently all of the security systems, would be set up using APPC or SNA to connect to your regional mainframe over one or more leased POTS lines.
The 3270 protocol that drove those green screens was screen oriented, if you changed two fields on the screen and hit ENTER, only the changed data from the fields would be sent, so having a bunch of terminals share a whopping 33kbps line wasn't outrageous.
From a programming and systems management perspective, the systems were designed to run as close to maximum utilization as possible. You just spent 10-15-20 million setting up this complex, you want to run it at 90-95% utilization 24 hours a day. So there's a whole set of workload management tools that developed by IBM, CA, and others to tweak applications and the operating environment to run it as hot as possible. There's all sorts of accounting built into the operating system(s) and language environments, going back to when you set literal budgets for how much a given department or program could spend.
So, this is the environment that ran from effectively the 1950s through the 1980s into the 1990s. The S/360 line launched in the early 1960s but offered some backwards compatibility to some IBM systems of the 1950s.
COBOL gets tagged as the most popular mainframe language but PL/1 (or PL/I) was frequently used (IBM had an internal variant called PL/X which was mostly used for systems software). C was used a lot as well inside IBM but usually for smaller products running inside VM/CMS.
I tried writing a web server for MVS in my spare time circa 1995–1996 and even though I was working with people inside MVS development we had a hard time getting it to work with what turned out to be a pretty crappy TCP/IP stack. The batch oriented nature of MVS wasn't the problem, IIRC the TCP/IP stack just could not handle the set up/tear down of the typical HTTP/0.9 and 1.0 connections. When a web server was eventually developed for MVS it was under the posix flavored "OpenEdition".
Net: It's just a different model of computing, with a different character set (EBCDIC, still) and languages. It's weird to see the industry kind of / sort of return to the classic shared computing resource model of the cloud with containerized applications and services. IBM in the 1990s was just as convinced at the corporate level that mainframes were dead as the consensus public opinion was at that time, which in retrospect is a shame since IBM chose to fire 1000s of people with the skills it would have needed to leverage to build a competitive cloud offering.