Re: Invalid character in file
I doubt that anybody is disparaging curved quotes. What I have seen is people disparaging software that covertly and inappropriately changes one character to another. I refer to such a program as a Molly Malone She died of a favor From which none could save her, And that was the end of sweet Molly Malone The ASCII quote character, the Unicode left quote and the Unicode right quote are all valid, but they are in no way interchangeable. Software that automatically "corrects" something that was not wrong is broken. "It's not a bug, it's a creature." There is nothing smart about "smart quotes", any more than it is smart to automatically capitalize things that are intended to be lower case. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Friday, October 29, 2021 12:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Invalid character in file Well, you're right of course. I saw the original question, thought "I think 1a is a SUB" and was going to look it up to be sure. Then someone else responded that it was a SUB and I just went with that. My bad. So the sequence may have been something like Input perhaps in UTF-8 translated to ASCII. Untranslatable character converted correctly to 1A. ASCII translated to EBCDIC and the 1A incorrectly preserved as 1A. 3270 emulator barfs on receipt of a 1A Will be interesting to hear back from the OP about my theory of a cut-and-paste of a curved quote. Hey, it is wrong to dis curved quotes. They are proper quotes. All quotes used to be curved quotes. Then the typewriter came along and they economized on keys by going to a single straight quote. ASCII and EBCDIC followed suit. Yes, automatic conversion of "typewriter quotes" to proper quotes can cause problems, but don't blame the quotes. They're right, at least historically speaking. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, October 28, 2021 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Invalid character in file On Thu, 28 Oct 2021 14:54:56 -0700, Charles Mills wrote: >1A is the EBCDIC sub character as @Mike says. Something is taking input in >character set A and translating it to character set B, finding a character >that is not in character set B, and properly substituting a 1A. > I believe 1A is the ASCII SUB; EBCDIC SUB is 3F. $ printf '\x1A' | iconv -f ISO8859-1 -t IBM-1047 | od -tx1 000 3f >Then TN3270 is saying "I don't know how to display a 1A" and barfing. > >Apostrophe, huh? A wild guess would be that the character that is not liked >might be a "smart quote": ’ > ITYM "smartass quote". But good guess. >I don't think they could truly key that in but they might count cut-and-paste >as "keying in." >-Original Message- >On Thu, Oct 28, 2021 at 8:24 PM Tony Thigpen wrote: >> >> This is a new one for me. >> >> I have a customer that has sites in both the US and Canada. In the last >> week, something strange has happened in their files TWICE. >> >> They are using CICS to add a new vendor to an IMS database. The next >> time they try to access the vendor record, the terminal session gets a >> prog-something because the customer name now has a x'1A' in the name >> where it should have been an apostrophe. TN3270 just does not like a >> x'1A' in a data field. >> >> For example: >> GROUT.S WELDING LIMITED >> CDDEE1E4ECDCCDC4DCDCECC44 >> 79643A2065349570394935400 >> >> I asked if they are creating new vendor records via an off-platform >> feed, but they say the are keying them manually in a CICS terminal session. >> >> I do know that both times this has happened, the vendor was a Canadian >> supplier so maybe this has something to do with French keyboards? >> (Grasping for straws, maybe?) >> >> Anybody seen this or think they may know what is happening? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Invalid character in file
Well, you're right of course. I saw the original question, thought "I think 1a is a SUB" and was going to look it up to be sure. Then someone else responded that it was a SUB and I just went with that. My bad. So the sequence may have been something like Input perhaps in UTF-8 translated to ASCII. Untranslatable character converted correctly to 1A. ASCII translated to EBCDIC and the 1A incorrectly preserved as 1A. 3270 emulator barfs on receipt of a 1A Will be interesting to hear back from the OP about my theory of a cut-and-paste of a curved quote. Hey, it is wrong to dis curved quotes. They are proper quotes. All quotes used to be curved quotes. Then the typewriter came along and they economized on keys by going to a single straight quote. ASCII and EBCDIC followed suit. Yes, automatic conversion of "typewriter quotes" to proper quotes can cause problems, but don't blame the quotes. They're right, at least historically speaking. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, October 28, 2021 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Invalid character in file On Thu, 28 Oct 2021 14:54:56 -0700, Charles Mills wrote: >1A is the EBCDIC sub character as @Mike says. Something is taking input in >character set A and translating it to character set B, finding a character >that is not in character set B, and properly substituting a 1A. > I believe 1A is the ASCII SUB; EBCDIC SUB is 3F. $ printf '\x1A' | iconv -f ISO8859-1 -t IBM-1047 | od -tx1 000 3f >Then TN3270 is saying "I don't know how to display a 1A" and barfing. > >Apostrophe, huh? A wild guess would be that the character that is not liked >might be a "smart quote": ’ > ITYM "smartass quote". But good guess. >I don't think they could truly key that in but they might count cut-and-paste >as "keying in." >-Original Message- >On Thu, Oct 28, 2021 at 8:24 PM Tony Thigpen wrote: >> >> This is a new one for me. >> >> I have a customer that has sites in both the US and Canada. In the last >> week, something strange has happened in their files TWICE. >> >> They are using CICS to add a new vendor to an IMS database. The next >> time they try to access the vendor record, the terminal session gets a >> prog-something because the customer name now has a x'1A' in the name >> where it should have been an apostrophe. TN3270 just does not like a >> x'1A' in a data field. >> >> For example: >> GROUT.S WELDING LIMITED >> CDDEE1E4ECDCCDC4DCDCECC44 >> 79643A2065349570394935400 >> >> I asked if they are creating new vendor records via an off-platform >> feed, but they say the are keying them manually in a CICS terminal session. >> >> I do know that both times this has happened, the vendor was a Canadian >> supplier so maybe this has something to do with French keyboards? >> (Grasping for straws, maybe?) >> >> Anybody seen this or think they may know what is happening? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Invalid character in file
On Thu, 28 Oct 2021 14:54:56 -0700, Charles Mills wrote: >1A is the EBCDIC sub character as @Mike says. Something is taking input in >character set A and translating it to character set B, finding a character >that is not in character set B, and properly substituting a 1A. > I believe 1A is the ASCII SUB; EBCDIC SUB is 3F. $ printf '\x1A' | iconv -f ISO8859-1 -t IBM-1047 | od -tx1 000 3f >Then TN3270 is saying "I don't know how to display a 1A" and barfing. > >Apostrophe, huh? A wild guess would be that the character that is not liked >might be a "smart quote": ’ > ITYM "smartass quote". But good guess. >I don't think they could truly key that in but they might count cut-and-paste >as "keying in." >-Original Message- >On Thu, Oct 28, 2021 at 8:24 PM Tony Thigpen wrote: >> >> This is a new one for me. >> >> I have a customer that has sites in both the US and Canada. In the last >> week, something strange has happened in their files TWICE. >> >> They are using CICS to add a new vendor to an IMS database. The next >> time they try to access the vendor record, the terminal session gets a >> prog-something because the customer name now has a x'1A' in the name >> where it should have been an apostrophe. TN3270 just does not like a >> x'1A' in a data field. >> >> For example: >> GROUT.S WELDING LIMITED >> CDDEE1E4ECDCCDC4DCDCECC44 >> 79643A2065349570394935400 >> >> I asked if they are creating new vendor records via an off-platform >> feed, but they say the are keying them manually in a CICS terminal session. >> >> I do know that both times this has happened, the vendor was a Canadian >> supplier so maybe this has something to do with French keyboards? >> (Grasping for straws, maybe?) >> >> Anybody seen this or think they may know what is happening? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Invalid character in file
It's probably a code page issue. What code point are they using for apostrophe in the name? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Thursday, October 28, 2021 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Invalid character in file This is a new one for me. I have a customer that has sites in both the US and Canada. In the last week, something strange has happened in their files TWICE. They are using CICS to add a new vendor to an IMS database. The next time they try to access the vendor record, the terminal session gets a prog-something because the customer name now has a x'1A' in the name where it should have been an apostrophe. TN3270 just does not like a x'1A' in a data field. For example: GROUT.S WELDING LIMITED CDDEE1E4ECDCCDC4DCDCECC44 79643A2065349570394935400 I asked if they are creating new vendor records via an off-platform feed, but they say the are keying them manually in a CICS terminal session. I do know that both times this has happened, the vendor was a Canadian supplier so maybe this has something to do with French keyboards? (Grasping for straws, maybe?) Anybody seen this or think they may know what is happening? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Invalid character in file
On Oct 28, 2021, at 4:54 PM, Charles Mills wrote: > > Apostrophe, huh? A wild guess would be that the character that is not liked > might be a "smart quote": ’ > > I don't think they could truly key that in but they might count cut-and-paste > as "keying in." +1. This is highly likely to be the cause. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Invalid character in file
1A is the EBCDIC sub character as @Mike says. Something is taking input in character set A and translating it to character set B, finding a character that is not in character set B, and properly substituting a 1A. Then TN3270 is saying "I don't know how to display a 1A" and barfing. Apostrophe, huh? A wild guess would be that the character that is not liked might be a "smart quote": ’ I don't think they could truly key that in but they might count cut-and-paste as "keying in." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, October 28, 2021 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Invalid character in file 1A is the SUB for invalid characters. Apparently the 3270 emulator (or file transfer program) is not using the standard apostrophe character. On Thu, Oct 28, 2021 at 8:24 PM Tony Thigpen wrote: > > This is a new one for me. > > I have a customer that has sites in both the US and Canada. In the last > week, something strange has happened in their files TWICE. > > They are using CICS to add a new vendor to an IMS database. The next > time they try to access the vendor record, the terminal session gets a > prog-something because the customer name now has a x'1A' in the name > where it should have been an apostrophe. TN3270 just does not like a > x'1A' in a data field. > > For example: > GROUT.S WELDING LIMITED > CDDEE1E4ECDCCDC4DCDCECC44 > 79643A2065349570394935400 > > I asked if they are creating new vendor records via an off-platform > feed, but they say the are keying them manually in a CICS terminal session. > > I do know that both times this has happened, the vendor was a Canadian > supplier so maybe this has something to do with French keyboards? > (Grasping for straws, maybe?) > > Anybody seen this or think they may know what is happening? > > > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Invalid character in file
1A is the SUB for invalid characters. Apparently the 3270 emulator (or file transfer program) is not using the standard apostrophe character. On Thu, Oct 28, 2021 at 8:24 PM Tony Thigpen wrote: > > This is a new one for me. > > I have a customer that has sites in both the US and Canada. In the last > week, something strange has happened in their files TWICE. > > They are using CICS to add a new vendor to an IMS database. The next > time they try to access the vendor record, the terminal session gets a > prog-something because the customer name now has a x'1A' in the name > where it should have been an apostrophe. TN3270 just does not like a > x'1A' in a data field. > > For example: > GROUT.S WELDING LIMITED > CDDEE1E4ECDCCDC4DCDCECC44 > 79643A2065349570394935400 > > I asked if they are creating new vendor records via an off-platform > feed, but they say the are keying them manually in a CICS terminal session. > > I do know that both times this has happened, the vendor was a Canadian > supplier so maybe this has something to do with French keyboards? > (Grasping for straws, maybe?) > > Anybody seen this or think they may know what is happening? > > > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
