4 ms·

Can someone answer a question for me? Is or was it ever true that booting Linux on a zSeries mainframe involves converting (part of?) the bootloader into 80-col

Can someone answer a question for me? Is or was it ever true that booting Linux on a zSeries mainframe involves converting (part of?) the bootloader into 80-column card sized chunks to feed into a virtual card reader? I remember hearing this once from a friend who'd had some zSeries training, but I was drunk at the time, so who knows.

tyingq 6y ago
You can boot from a z/VM reader, which would be a virtual card reader, but it's not the only option. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-s390-steps-boot#s1-s390-steps-boot-Installing_under_zVM-zVM_Reader https://access.redhat.com/documentation/en-us/red_hat_enterp... The actual booting part is a REXX CMS script, and you can see the references to punchcards within: /* CMS EXEC script to punch RHEL 64-bit install */ 'CP SPOOL PUN *' 'CP CLOSE RDR' 'PUR RDR ALL' 'PUN KERNEL IMG * (NOH' 'PUN 'userid()' PARM * (NOH' 'PUN INITRD IMG * (NOH' 'CH RDR ALL KEEP' 'IPL 00C CLEAR' It's not as terrible as it sounds. It just turns kernel.img and initrd.img from stream files into record based files with records of 80 bytes.
- 082349872349872 6y ago
  From the linux side, dd(1) has blocking/unblocking and EBCDIC/ASCII conversions as well. IPL IIRC was "Initial Program Load", and I'm guessing PUN would be "Punch" but since it's converting file formats I'd like to read it as "pun".
  - skissane 6y ago
    > From the linux side, dd(1) has blocking/unblocking and EBCDIC/ASCII conversions as well. dd's built-in EBCDIC/ASCII conversion is terrible. It doesn't use any proper IBM codepage (such as EBCDIC 37 or EBCDIC 1047). It is based on the character set of some random mainframe printer at Bell Labs in the 1970s. As a result, it tends to garble punctuation (especially square brackets). iconv can do it correctly – provided your copy of iconv has the EBCDIC conversion support compiled-in. Ubuntu's does, macOS' doesn't. Most 8-bit ASCII codes (e.g. ISO 8859-n, UTF-8) are based on US-ASCII, where the first 128 characters are always at the same locations, including the punctuation marks traditionally used in programming. By contrast, different EBCDIC code pages put those punctuation marks at different locations. Even for US English text, there are two different EBCDIC code pages in common use, with different codes for square brackets, exclamation mark and pipe symbol – IBM 37 is the main traditional US English EBCDIC code page, and IBM 1047 is a variant originally devised for use with POSIX. UK English, and other European languages, add even more. https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/char/src/tpc/db2z_codeptdiffebcdic.html https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/ch... covers some of these details, although it doesn't go into the history behind it.
    - colejohnson66 6y ago
      So EBCDIC is like “ASCII” in that there isn’t one true definition (people making 8 bit code pages and claiming it was ASCII)?
      - meepmorp 6y ago
        Kind of, but the incompatible versions all come from IBM.
        skissane 6y ago
        Although IBM invented EBCDIC, other vendors adopted it, and some of those other vendors created their own slightly incompatible versions of it as well. For example, Unisys mainframes (running MCP) have their own EBCDIC variant called "ASERIESEBCDIC" (named for its A Series mainframes). They also support another EBCDIC variant called "STDEBCDIC" ("Standard EBCDIC"), which I am guessing by its name is more compatible with IBM's (although I'm not sure which IBM code page it corresponds to)
      - skissane 6y ago
        Even if we limit ourselves to 7-bit codes, ASCII still doesn't have one true definition. US-ASCII was first published in 1963. In 1967, a new revision was published which changed some of the characters – most significantly, left arrow was replaced by underscore and up arrow was replaced by caret, although also some control characters were renamed/replaced. The vast majority of systems nowadays use the 1967 revision, which is also the basis of subsequent standards such as ISO-8859 and UTF-8. However, the 1963 standard did see some historically significant use – Smalltalk adopted it, and even today some Smalltalk implementations display up and left arrow instead of caret and underscore. It also influenced the choice to use the caret for exponentiation in languages such as BASIC (the original Dartmouth BASIC used 1963 ASCII rather than 1967.) The ASCII extension used by 8-bit Commodore systems (PET, VIC-20, C64, etc), PETSCII, is also based on the 1963 edition of ASCII rather than the 1967. There is also the broader family of compatible 7-bit codes of which US-ASCII is a member – ISO 646. ISO 646 codes take US-ASCII, and replace up to 12 punctuation symbols with symbols needed in non-US-English text. Some people will say that only US-ASCII is ASCII, and these other derived 7-bit codes are not. On the other hand, the very existence of the term "US-ASCII" (which is IANA's preferred term) suggests that these other variants are ASCIIs too, and the original is just the ASCII for the US. Indeed, the original developers of ASCII foresaw and expected the development of variants of it for non-US use. It was only the later development of 8-bit codes (and then even bigger codes, such as ISO 2022 and Unicode) which meant everyone could standardise on the US version. And the fact that popular programming languages ended up using (close to) the full complement of US-ASCII punctuation marks gave people the motivation to do so – others you had to rely on ugly hacks such as C and C++'s trigraphs and digraphs.
- meepmorp 6y ago
  Thanks! It totally makes sense that you'd have a mechanism for booting an image like that, considering how heavily mainframes use virtualization and how insanely backward compatible they are.
  - tyingq 6y ago
    Right, it's klunky, but doesn't seem much different from what you see around BIOS/UEFI/grub and so on.
    - meepmorp 6y ago
      I find something appealing about how the vestigial remnants of physically punched cards are retained to boot the OS, even though they don't really make sense any more. It's weirdly reminiscent of biological evolution, where systems get retained and repurposed even if they're not the most efficient way something could be implemented.
deleted 6y ago
[deleted]

tyingq 6y ago

You can boot from a z/VM reader, which would be a virtual card reader, but it's not the only option. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-s390-steps-boot#s1-s390-steps-boot-Installing_under_zVM-zVM_Reader https://access.redhat.com/documentation/en-us/red_hat_enterp... The actual booting part is a REXX CMS script, and you can see the references to punchcards within: /* CMS EXEC script to punch RHEL 64-bit install */ 'CP SPOOL PUN *' 'CP CLOSE RDR' 'PUR RDR ALL' 'PUN KERNEL IMG * (NOH' 'PUN 'userid()' PARM * (NOH' 'PUN INITRD IMG * (NOH' 'CH RDR ALL KEEP' 'IPL 00C CLEAR' It's not as terrible as it sounds. It just turns kernel.img and initrd.img from stream files into record based files with records of 80 bytes.

082349872349872 6y ago
From the linux side, dd(1) has blocking/unblocking and EBCDIC/ASCII conversions as well. IPL IIRC was "Initial Program Load", and I'm guessing PUN would be "Punch" but since it's converting file formats I'd like to read it as "pun".
- skissane 6y ago
  > From the linux side, dd(1) has blocking/unblocking and EBCDIC/ASCII conversions as well. dd's built-in EBCDIC/ASCII conversion is terrible. It doesn't use any proper IBM codepage (such as EBCDIC 37 or EBCDIC 1047). It is based on the character set of some random mainframe printer at Bell Labs in the 1970s. As a result, it tends to garble punctuation (especially square brackets). iconv can do it correctly – provided your copy of iconv has the EBCDIC conversion support compiled-in. Ubuntu's does, macOS' doesn't. Most 8-bit ASCII codes (e.g. ISO 8859-n, UTF-8) are based on US-ASCII, where the first 128 characters are always at the same locations, including the punctuation marks traditionally used in programming. By contrast, different EBCDIC code pages put those punctuation marks at different locations. Even for US English text, there are two different EBCDIC code pages in common use, with different codes for square brackets, exclamation mark and pipe symbol – IBM 37 is the main traditional US English EBCDIC code page, and IBM 1047 is a variant originally devised for use with POSIX. UK English, and other European languages, add even more. https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/char/src/tpc/db2z_codeptdiffebcdic.html https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/ch... covers some of these details, although it doesn't go into the history behind it.
  - colejohnson66 6y ago
    So EBCDIC is like “ASCII” in that there isn’t one true definition (people making 8 bit code pages and claiming it was ASCII)?
    - meepmorp 6y ago
      Kind of, but the incompatible versions all come from IBM.
      - skissane 6y ago
        Although IBM invented EBCDIC, other vendors adopted it, and some of those other vendors created their own slightly incompatible versions of it as well. For example, Unisys mainframes (running MCP) have their own EBCDIC variant called "ASERIESEBCDIC" (named for its A Series mainframes). They also support another EBCDIC variant called "STDEBCDIC" ("Standard EBCDIC"), which I am guessing by its name is more compatible with IBM's (although I'm not sure which IBM code page it corresponds to)
    - skissane 6y ago
      Even if we limit ourselves to 7-bit codes, ASCII still doesn't have one true definition. US-ASCII was first published in 1963. In 1967, a new revision was published which changed some of the characters – most significantly, left arrow was replaced by underscore and up arrow was replaced by caret, although also some control characters were renamed/replaced. The vast majority of systems nowadays use the 1967 revision, which is also the basis of subsequent standards such as ISO-8859 and UTF-8. However, the 1963 standard did see some historically significant use – Smalltalk adopted it, and even today some Smalltalk implementations display up and left arrow instead of caret and underscore. It also influenced the choice to use the caret for exponentiation in languages such as BASIC (the original Dartmouth BASIC used 1963 ASCII rather than 1967.) The ASCII extension used by 8-bit Commodore systems (PET, VIC-20, C64, etc), PETSCII, is also based on the 1963 edition of ASCII rather than the 1967. There is also the broader family of compatible 7-bit codes of which US-ASCII is a member – ISO 646. ISO 646 codes take US-ASCII, and replace up to 12 punctuation symbols with symbols needed in non-US-English text. Some people will say that only US-ASCII is ASCII, and these other derived 7-bit codes are not. On the other hand, the very existence of the term "US-ASCII" (which is IANA's preferred term) suggests that these other variants are ASCIIs too, and the original is just the ASCII for the US. Indeed, the original developers of ASCII foresaw and expected the development of variants of it for non-US use. It was only the later development of 8-bit codes (and then even bigger codes, such as ISO 2022 and Unicode) which meant everyone could standardise on the US version. And the fact that popular programming languages ended up using (close to) the full complement of US-ASCII punctuation marks gave people the motivation to do so – others you had to rely on ugly hacks such as C and C++'s trigraphs and digraphs.
meepmorp 6y ago
Thanks! It totally makes sense that you'd have a mechanism for booting an image like that, considering how heavily mainframes use virtualization and how insanely backward compatible they are.
- tyingq 6y ago
  Right, it's klunky, but doesn't seem much different from what you see around BIOS/UEFI/grub and so on.
  - meepmorp 6y ago
    I find something appealing about how the vestigial remnants of physically punched cards are retained to boot the OS, even though they don't really make sense any more. It's weirdly reminiscent of biological evolution, where systems get retained and repurposed even if they're not the most efficient way something could be implemented.

deleted 6y ago

[deleted]