The 129 keypunch could INTERPRET lower case in already-punched cards, but just like 029 (and 026 even) ENTERING lower case required multi-punch.
No professional keypunch operator ever entered lower case letters. It would have required remembering the multi-punch combination for all the letters and would have destroyed their "cards per hour" rating, on which their jobs frequently depended. I know because I had that job early in my career before I got my first programming job. Had to do something to pay the rent. Some keypunch supervisors were absolutely ruthless about keeping "cards per hour" high across their shop, and you could lose your job if you couldn't keep up. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, April 30, 2019 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Upper case for ISPF and SDSF On Tue, 30 Apr 2019 17:02:13 +0000, Seymour J Metz wrote: >I recall, e.g., the 129, printing lower case. > Google is uninformative on the topic, but your memory is usually good. I never used anything beyond 029. Had it a caps key, or was multi-punch necessary? On Tue, 30 Apr 2019 06:44:05 +0000, Gadi Ben-Avi wrote: > ... >The reason goes back a few decades, way before my time. >In the beginning, when we needed to print Hebrew, the Hebrew characters >replaced English Upper case. This was before there were even terminals. >In the next stage, Hebrew Characters replaced the English lower case letters, >so we could print and display (there were terminals by this stage) both >English Upper case and Hebrew on the same display or report. >At this stage someone wrote a huge ISPF application. This is one of the main >reasons that we still use this encoding. >The current and up to date encoding (EBCDIC 424) can display and print English >upper case, English lower case and Hebrew. > >In the past, I tried to attempt to convert the ISPF application to EBCDIC-424. >The problem I encountered was with the &. > EBCDIC-424 has '&' at 0x50 (where it's supposed to be) and 'א' at 0x41 (sometimes NBSP). It would require an expert system to differentiate between '&' and 'א' if both occur in the same document. >The English alphabet has 26 characters, The Hebrew alphabet has 27. Way >back some decided that The first letter of the Hebrew alphabet, aleph, would >be replaced by the & character (x'50') The & is also used as the variable >identifier in the CLIST and PANEL languages, so it's very hard to know if an & >represents the character aleph or an &. > But resorting to an all-caps code page does nothing to resolve this ambiguity. Usurping an EBCDIC-invariant code point when so many uncommited code points existed was inexcusable. And Timothy omitted mention: https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/nls/rbagsinvariantcharset.htm ... that: o EBCDIC code page 290 has Katakana characters at the code points where lowercase a through z are in the invariant character set ... sufficient reason for Japanese to eschew lowercase. >On 4/28/2019 10:43 PM, Gadi Ben-Avi wrote: >> I found a solution. >> There is an optional FMID you can download and install called JIF7R16 that >> adds libraries with upper case only versions of the panels, messages and >> some other libraries. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
