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
0000000 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 [email protected] with the message: INFO IBM-MAIN
