Ethernet (OSA cards) and Fibre Channel (FICON cards) are standard on z Mainframes these days. TCP/IP is standard on z/OS, CP (z/VM), AIX and Linux. Terminal emulators connect over TCP/IP, not RS-232 or coax. etc.
But still today:
- The character set for most OSes (not Linux) is EBCDIC.
- The terminal is form-based (like a web page, but with invisible input fields) rather than character based.
- You ALWAYS have to have key punch and card reader devices defined (even on Linux).
- z/OS needs proprietary FICON (not plain fibre channel) connections to emulated ECKD disks (not block based) on one of just a few SANs that support it.
- VSE still needs a TCP/IP stack (one of two 3rd party vendors) purchased separately.
- You need several x86 computers (HMC and two support elements) to manage or even boot-up a mainframe.
- You have to painstakingly configure virtual to physical device address mappings (IOCDS) before you can boot-up anything.
> - You ALWAYS have to have key punch and card reader devices defined (even on Linux).
Linux doesn’t actually support physical card readers/punches, only paravirtualized readers/punches under z/VM (implemented using DIAG hypervisor call interface). [0] And that’s because paravirtualized card devices are heavily used under z/VM for IPC (inter-VM communication), although there are alternatives (IUCV, TCP/IP). So if you aren’t running under z/VM, Linux can’t use readers/punches, because the hypervisor interface isn’t there. And even under z/VM, Linux will work fine without them, because they are mainly used for sending data between Linux and other mainframe operating systems such as CMS and RSCS, and maybe you aren’t interested in that. And if somehow you managed to connect a real card reader or punch to your mainframe (you’d need to chain together a bus/tag to ESCON bridge with an ESCON to FICON bridge), bare metal Linux would have no idea how to talk to it, because it doesn’t support real card devices, only paravirtualized ones. Linux under z/VM might be able to do so, by relying on the hypervisor’s card device driver.
[0] Have a look at https://github.com/torvalds/linux/blob/v6.10/drivers/s390/ch... – if it encounters a real card reader/punch, it is hardcoded to return -EOPNOTSUPP. Actually it looks like it does use CCWs to write to punches, but it relies on DIAG for reading from card readers and device discovery. And due to that code, even if it is generating the correct CCWs to write to a physical punch (I don't know), it would refuse to do so.
> Linux under z/VM might be able to do so, by relying on the hypervisor’s card device driver.
Actually thinking more about the code I linked, I don’t think this would work - even if the z/VM hypervisor (CP) still knows how to talk to physical card devices (maybe the code has bitrotted, or maybe IBM has removed it as legacy cruft) - the DIAG interface would report it as a physical/real device, and hence that Linux kernel driver would refuse to talk to it
But still today:
- The character set for most OSes (not Linux) is EBCDIC.
- The terminal is form-based (like a web page, but with invisible input fields) rather than character based.
- You ALWAYS have to have key punch and card reader devices defined (even on Linux).
- z/OS needs proprietary FICON (not plain fibre channel) connections to emulated ECKD disks (not block based) on one of just a few SANs that support it.
- VSE still needs a TCP/IP stack (one of two 3rd party vendors) purchased separately.
- You need several x86 computers (HMC and two support elements) to manage or even boot-up a mainframe.
- You have to painstakingly configure virtual to physical device address mappings (IOCDS) before you can boot-up anything.
And more.