Re: Subject Unicode

In , on 01/13/2014 at 02:27 PM, Tony Harminc said: >But no one would say that UTF-8 *is* >ASCII, or that UTF-EBCDIC *is* EBCDIC. Well, all ASCII characters are valid single octet UTF-8 sequences, so I would say that ASCII is a subset of UTF-8.mAs for EBCDIC, there were already multiple EBCDIC

Re: Subject Unicode

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Monday, January 13, 2014 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode On 12 January 2014 10:21, Shmuel Metz (Seymour J.) wrote: > on 01/09/2014 at 09:00 PM, Tony Harminc said: > >&

Re: Subject Unicode

On Mon, Jan 13, 2014 at 1:27 PM, Tony Harminc wrote: > On 12 January 2014 10:21, Shmuel Metz (Seymour J.) > wrote: > > on 01/09/2014 at 09:00 PM, Tony Harminc said: > > > >>There is no general way to convert UNICODE into EBCDIC, > > > > There are EBCDIC transforms for Unicode. I'm not sure whet

Re: Subject Unicode

On 12 January 2014 10:21, Shmuel Metz (Seymour J.) wrote: > on 01/09/2014 at 09:00 PM, Tony Harminc said: > >>There is no general way to convert UNICODE into EBCDIC, > > There are EBCDIC transforms for Unicode. I'm not sure whether that qulifies > as EBCDIC. Exactly as much as UTF-8 qualifies a

Re: Subject Unicode (Also email. Also TAB.)

On Sun, 12 Jan 2014 13:09:40 -0500, Shmuel Metz (Seymour J.) wrote: > >>Thereby sacrificing some small economy of storage. There are even >>better arguments for deferring the disambiguation, such as: > >>o Use of tabs as field separators in exported data bases. > >>o Rendering in proportional-spac

Re: Subject Unicode

On Sun, Jan 12, 2014 at 5:28 PM, Paul Gilmartin wrote: > On Sun, 12 Jan 2014 15:48:49 -0600, Kirk Wolf wrote: > > >On Linux gedit works fine, on Windows I use Notepad++ which handles Unix > >eols and UTF-8 > > > You mean I don't have to wait for Windows 14!? Thanks! > > Does it do UNIX eols on in

Re: Subject Unicode

In , on 01/12/2014 at 05:11 PM, John Gilmore said: >If I argued that the comments prefixed to a routine described its >putative algorithm correctly and that the routine itself could thus >contain no error, Shmuel would still hopefully be quick to point out >the inadequacy of my argument; but h

Re: Subject Unicode

In <8160871980876269.wa.paulgboulderaim@listserv.ua.edu>, on 01/12/2014 at 03:28 PM, Paul Gilmartin said: >Doesn't understand UNIX line breaks. I don't FTP text files as binary. NOTEPAD doesn't introduce fancy formatting that I didn't request and don't want. For me, that makes it supperi

Re: Subject Unicode

In <20140111220658.62ce18f...@panix3.panix.com>, on 01/11/2014 at 05:06 PM, Don Poitras said: >I don't know how these characters are going to survive email, Not without proper[1] MIME header fields; characters like, e.g., Copyright (©), Euro (€), Registered (®), Yen (¥), are not ASCII. [1] E

Re: Subject Unicode (Also email. Also TAB.)

In <52d2d540.1020...@t-online.de>, on 01/12/2014 at 06:47 PM, Bernd Oppolzer said: >IMO, the idea to put tab characters into files is wrong from the >beginning. I don't agree; it's useful for text markup. I don't like taking away a printable character as a logical tab. -- Shmuel (Seym

Re: Subject Unicode (Also email. Also TAB.)

In <7503442349556875.wa.paulgboulderaim@listserv.ua.edu>, on 01/12/2014 at 09:55 AM, Paul Gilmartin said: >Thereby sacrificing some small economy of storage. There are even >better arguments for deferring the disambiguation, such as: >o Use of tabs as field separators in exported data ba

Re: Subject Unicode

Some words about editors, tabs, eolchar, eofchar. The editor which I like most does the following: - read files that have CRLF eols or LF eols - output files with CRLF or LF, controlled by an editor setting - output an EOF char, if desired (0x1a); most of the time, I don't want it - allow indivi

Re: Subject Unicode

On Sun, 12 Jan 2014 15:48:49 -0600, Kirk Wolf wrote: >On Linux gedit works fine, on Windows I use Notepad++ which handles Unix >eols and UTF-8 > You mean I don't have to wait for Windows 14!? Thanks! Does it do UNIX eols on in put *and* output? Wordpad only does the former. Thanks again, gil

Re: Subject Unicode

I don't generally respond to Shmuel's animadversions. This time, however, he has crossed the line of civilized behavior. His experience with Unicode appears to be limited to attentive reading of its defining documents. Its implementations are, unsurprisingly, imperfect. In particular the severa

Re: Subject Unicode

BTW, Notepad++ is not only free/open source, but it also has the goal of preventing Global Warming :-) http://notepad-plus-plus.org/ .. while at the same time likes to show off: http://notepad-plus-plus.org/features/column-mode-editing.html Kirk Wolf Dovetailed Technologies http://dovetail.co

Re: Subject Unicode (Also email. Also TAB.)

Tabs are useful for formatting input text. I use tab settings of 10, 16. 35, and 72 for HLASM source formatting; but I will not use a text editor that does not---optionally for those who have other preferences---replace tabs with blanks during save/storage operations. Bernd and I are thus in comp

Re: Subject Unicode

On Linux gedit works fine, on Windows I use Notepad++ which handles Unix eols and UTF-8 Kirk Wolf Dovetailed Technologies http://dovetail.com On Sun, Jan 12, 2014 at 3:28 PM, Paul Gilmartin wrote: > On Sun, 12 Jan 2014 10:45:23 -0500, Shmuel Metz (Seymour J.) wrote: > > > >>"Notepad"? What's t

Re: Subject Unicode

On Sun, 12 Jan 2014 10:45:23 -0500, Shmuel Metz (Seymour J.) wrote: > >>"Notepad"? What's that? Perhaps some obsolete predecessor of >>Wordpad? > >No, it's a superior version of wordpad. HTH. > Doesn't understand UNIX line breaks. For me that's a deal breaker. -- gil -

Re: Subject Unicode (Also email. Also TAB.)

On Sun, 12 Jan 2014 18:59:25 +0100, Bernd Oppolzer wrote: > >second: from the moment on when we terminated to exchange >files by paper tape, we should have stopped to put tabs into files >from that same moment on - if not before. My opinion ... > Why? Where else would you keep them? >> Regards t

Re: Subject Unicode (Also email. Also TAB.)

Am 12.01.2014 19:10, schrieb Ted MacNEIL: you have the problem to decide what tab positions this file is meant to have, and you always have to guess, and it's wrong most of the time, and the result looks awful Your solution would also look awful with proportional text. My focus is on source

Re: Subject Unicode (Also email. Also TAB.)

>you have the problem to decide what tab positions this file is meant to have, and you always have to guess, and it's wrong most of the time, and the result looks awful Your solution would also look awful with proportional text. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL

Re: Subject Unicode (Also email. Also TAB.)

Two short additions: first: "Regards" in the 4th paragraph is a sort of typo, should read "Regarding" second: from the moment on when we terminated to exchange files by paper tape, we should have stopped to put tabs into files from that same moment on - if not before. My opinion ... Kind regard

Re: Subject Unicode

In <20140110195944.3d5f333...@panix2.panix.com>, on 01/10/2014 at 02:59 PM, Don Poitras said: >As far as 3270 goes, I think it's just going to us the CODEPAGE and >CHARSET you start ISPF with. I think it's going to be limited to the >set of EBCDIC code pages. As this is the first release, I'm

Re: Subject Unicode

In , on 01/10/2014 at 01:28 PM, John Gilmore said: >Briefly, effective rules for encoding any 'character' recognized as a >Unicode one as a 'longer' UTF-8 one do not in general exist. What are you drinking? RFC 3629 spells them out in excruciating detail. >In dealing recently with a documen

Re: Subject Unicode

In , on 01/10/2014 at 09:50 AM, John Gilmore said: >As soon, however, as you need to support >o three or more different roman-alphabet natural languages, or >o a roman-alphabet language and a non-alphabetic Asian language >you need UTF-16. Nonsense; it's strictly an efficiency issue, and

Re: Subject Unicode

In , on 01/10/2014 at 11:02 AM, John Gilmore said: >The problem is not one of representability but of subset choice. There is no problem of subset choice, because use of UTF-8 does not imply a proper subset of Unicode; it is a tranform for all 2^20 minus[1] code points. [1] U+D800 through U

Re: Subject Unicode

In <9931357931112854.wa.paulgboulderaim@listserv.ua.edu>, on 01/10/2014 at 08:41 AM, Paul Gilmartin said: >"Notepad"? What's that? Perhaps some obsolete predecessor of >Wordpad? No, it's a superior version of wordpad. HTH. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO p

Re: Subject Unicode

In , on 01/10/2014 at 09:36 AM, Harry Wahl said: >You could use the "BOM" UTF characters There are none. U+FEFF "ZERO WIDTH NO-BREAK SPACE" is a Unicode character. >usually inserted transparently at the beginning of a UTF file. Usually inserted *only* at the beginning of a file transmitt

Re: Subject Unicode

In , on 01/10/2014 at 03:30 PM, Timothy Sipples said: >Somehow I'm reminded of the "save two characters" impulse which then >caused a lot of angst in preparing for Y2K. The situations are not comparable. With 2-digit years there was an actual truncation of the data. With UTF-7 or UTF-8, all o

Re: Subject Unicode

In <20140110034419.c71008f...@panix3.panix.com>, on 01/09/2014 at 10:44 PM, Don Poitras said: >As of z/OS 2.1, ISPF supports UTF-8, so a binary transfer will still >show an A if it was an A on the PC. Only if the PC was using UTF-8 or translates to Unicode with UTF-8 as part of the transmissi

Re: Subject Unicode

In , on 01/09/2014 at 09:00 PM, Tony Harminc said: >There is no general way to convert UNICODE into EBCDIC, There are EBCDIC transforms for Unicode. I'm not sure whether that qulifies as EBCDIC. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: Subject Unicode

In <0e75a300-f7c5-46a7-a1d3-7189d2a58...@yahoo.com>, on 01/09/2014 at 08:39 PM, Scott Ford said: >We send a data message from a pc, we encrypt it with AES128 , the >message is received at the host (z/OS) decrypted then converted from >ascii to ebcdic If it really was ASCII then it would be cu

Re: Subject Unicode

In <022c01cf0da5$a7b25180$f716f480$@mcn.org>, on 01/09/2014 at 05:45 PM, Charles Mills said: >There are several flavors of Unicode, but they relate to how the >code points are stored in a file or transmitted, not to the >character set. Actually, those are transforms rather than different flav

Re: Subject Unicode

In <1389314155.47172.yahoomail...@web126205.mail.ne1.yahoo.com>, on 01/09/2014 at 04:35 PM, Scott Ford said: >PC ( data using a foreign language Unicode page What are you trying to say? If the PC is using Unicode then it will transimit data as UTF-7 or UTF-8, which covers the entire BMP and b

Re: Subject Unicode (Also email. Also TAB.)

IMO, the idea to put tab characters into files is wrong from the beginning. But of course it comes from the paper tape paradigma, where a file is historically a paper tape feeding a teletype machine. With normal "local" typewriters, a tab is nothing other than a command to the typewriter to po

Re: Subject Unicode (Also email. Also TAB.)

On Sun, 12 Jan 2014 10:29:22 -0500, John Gilmore wrote: > >... [Tabs'] effects depend upon local tab settings, and many >implementations disambiguate them by replacing them with blanks of >currently equivalent effect in saved/stored files. > Thereby sacrificing some small economy of storage. The

Re: Subject Unicode (Also email. Also TAB.)

On the several keyboards I have at hand tab is modal, right or left depending upon the current shift-key setting. The modal marking appears to be | tab| | <—— | | ——> | in which the 'arrowheads' are solid, not open. I should think that '>|' would be adequately perspicuous. The not

Re: Subject Unicode (Also email. Also TAB.)

On Sun, 12 Jan 2014 03:48:45 -0500, Ed Finnell wrote: >It might survive as .txt attachment. Everything else gets sliced and diced. > Depends on the MUA. The text I submitted earlier by email: ==> Polyglot <== A common Russian phrase is "ОЧЕНЬ ХОРОШО". The Greek might be "ΠΟΛΥ ΚΑΛΑ.

Re: Subject Unicode

It might survive as .txt attachment. Everything else gets sliced and diced. In a message dated 1/11/2014 4:15:43 P.M. Central Standard Time, poit...@pobox.com writes: Yeah, I didn't think that would work. :) If you're reading this as I am, all the (well most of) text below ended up as ??.

Re: Subject Unicode

Yeah, I didn't think that would work. :) If you're reading this as I am, all the (well most of) text below ended up as ??. In actuality, every ?? was a single width. The first line contains 16 characters with 32 hex bytes underneath. The subsequent lines are all a single character with 2 hex bytes

Re: Subject Unicode

In article you wrote: > (Cross posting to ISPF-L and IBM-MAIN) > On 2014-01-10, at 12:59, Don Poitras wrote: > > > >>> As of z/OS 2.1, ISPF supports UTF-8, so a binary transfer will still show > >>> an A if it > >>> was an A on the PC. ... > >> What representation does it use in the 3270 dat

Re: Subject Unicode

(Cross posting to ISPF-L and IBM-MAIN) On 2014-01-10, at 12:59, Don Poitras wrote: > >>> As of z/OS 2.1, ISPF supports UTF-8, so a binary transfer will still show >>> an A if it >>> was an A on the PC. ... >> What representation does it use in the 3270 data streams? Is >> this well documente

Re: Subject Unicode

Coming in Windows 14: WordNote, which will handle UTF-8 *and* UNIX line separators!!! On Fri, Jan 10, 2014 at 5:52 PM, Paul Gilmartin wrote: > On Fri, 10 Jan 2014 10:44:10 -0700, Steve Comstock wrote: > > >On 1/10/2014 10:28 AM, zMan wrote: > >> Cute. Notepad still exists in current Windows, btw

Re: Subject Unicode

On 1/10/2014 3:52 PM, Paul Gilmartin wrote: On Fri, 10 Jan 2014 10:44:10 -0700, Steve Comstock wrote: On 1/10/2014 10:28 AM, zMan wrote: Cute. Notepad still exists in current Windows, btw. And it handles utf-8 fine. Notepad handles UTF-8 fine (on a scientific sample of 1). But it's utter

Re: Subject Unicode

On Fri, 10 Jan 2014 10:44:10 -0700, Steve Comstock wrote: >On 1/10/2014 10:28 AM, zMan wrote: >> Cute. Notepad still exists in current Windows, btw. > >And it handles utf-8 fine. > Notepad handles UTF-8 fine (on a scientific sample of 1). But it's utterly ignorant of UNIX line separators. Word

Re: Subject Unicode

I have not been able to identify a defect in the scheme specified for UTF-16 to UTF-8. I have pointed to implementations that are sometimes unsuccessful, and their failures have some common characteristics. For now, I avoid UTF-8 when I can. I expect that it will be problem-free at some not at a

Re: Subject Unicode

On Jan 10, 2014, at 3:10 PM, John Gilmore wrote: > I have, however, found all of the UTF-8 implementations I have used > both unsatisfactory and unreliable in the literal sense that > conversions into UTF-8 from UTF-16 using them do not always yield the > same results. Is the issue related to su

Re: Subject Unicode

ry 10, 2014 4:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode I am familiar with Unicode. Wikipedia assertions of this or that about it do not persuade me of much of anything. Moreover, as a review of the archives will show, I am an advocate of its use. I have, however, found a

Re: Subject Unicode

I am familiar with Unicode. Wikipedia assertions of this or that about it do not persuade me of much of anything. Moreover, as a review of the archives will show, I am an advocate of its use. I have, however, found all of the UTF-8 implementations I have used both unsatisfactory and unreliable i

Re: Subject Unicode

On 10 January 2014 13:28, John Gilmore wrote: > Briefly, effective rules for encoding any 'character' recognized as a > Unicode one as a 'longer' UTF-8 one do not in general exist. I am most puzzled to read this. UTF-8 is what Unicode calls a "transform format", and the conversion from other enco

Re: Subject Unicode

In article <8790842028980392.wa.paulgboulderaim@listserv.ua.edu> you wrote: > On Thu, 9 Jan 2014 22:44:19 -0500, Don Poitras wrote: > >As of z/OS 2.1, ISPF supports UTF-8, so a binary transfer will still show an > >A if it > >was an A on the PC. ... > > > Does this support both UNIX and lega

Re: Subject Unicode

On Jan 10, 2014, at 12:28 PM, John Gilmore wrote: > Briefly, effective rules for encoding any 'character' recognized as a > Unicode one as a 'longer' UTF-8 one do not in general exist. Sure they do. From http://www.unicode.org/faq/utf_bom.html#UTF8: "UTF-8 is the byte-oriented encoding form of

Re: Subject Unicode

Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, January 10, 2014 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode Paul, No, I do not accept the premises you set out. I will try, when I have more time, to make clear why with examples. Briefly

Re: Subject Unicode

Paul, No, I do not accept the premises you set out. I will try, when I have more time, to make clear why with examples. Briefly, effective rules for encoding any 'character' recognized as a Unicode one as a 'longer' UTF-8 one do not in general exist. Moreover, even when they are available, my ex

Re: Subject Unicode

On 1/10/2014 10:28 AM, zMan wrote: Cute. Notepad still exists in current Windows, btw. And it handles utf-8 fine. -Steve On Fri, Jan 10, 2014 at 9:41 AM, Paul Gilmartin wrote: On Fri, 10 Jan 2014 09:36:32 -0500, Harry Wahl wrote: ... Windows Notepad is particularly tricky because it a

Re: Subject Unicode

Cute. Notepad still exists in current Windows, btw. On Fri, Jan 10, 2014 at 9:41 AM, Paul Gilmartin wrote: > On Fri, 10 Jan 2014 09:36:32 -0500, Harry Wahl wrote: > > > >... Windows Notepad is particularly tricky because it adds them without > you realizing it. So whether you look at a file with

Re: Subject Unicode

oding/all . Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, January 10, 2014 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode On Fri, 10 Jan 2014 11:02:57 -0500, John Gilmore wrote: >Charle

Re: Subject Unicode

On Fri, 10 Jan 2014 11:02:57 -0500, John Gilmore wrote: >Charles > >I do not think you read my post at all carefully. > >I made it clear that for specific language pairs UTF-8 is adequate if >often clumsy. > >For multiple-language environments it is equally clear that it is inadequate. > >It is of

Re: Subject Unicode

Charles I do not think you read my post at all carefully. I made it clear that for specific language pairs UTF-8 is adequate if often clumsy. For multiple-language environments it is equally clear that it is inadequate. It is of course true that any grapheme, even say some company's logo or an

Re: Subject Unicode

historical reference 1960-1979 http://www.bobbemer.com/REGISTRY.HTM ibm major driver behind all this http://www.bobbemer.com/ZACHERLY.HTM however, Learson had problem and made decision to temporarily go with EBCDIDC w/o realizing what he had done ("The Biggest Computer Goof Ever) ... and the comp

Re: Subject Unicode

Gil: Co:Z SFTP and DatasetPipes both support any single-byte encoding as well as UTF-8 when converting to/from datasets. You can use either iconv or unicode system services, including custom tables and techniques. Scott: What is a "foreign language" Unicode page? Can you give a specific exampl

Re: Subject Unicode

ssage- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Thursday, January 09, 2014 11:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode Charles Mills writes: >You could use 16 bits for every character, with some sort of cle

Re: Subject Unicode

UTF-8 won. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, January 10, 2014 6:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode I have refrained from saying anything about this topic

Re: Subject Unicode

I have refrained from saying anything about this topic because I judged that anything I said would be predictable. I am a well-known offender, a flagrant Unicode, i.e., minimally UTF-16, advocate. Now, however, Charles Mills has pushed me into posting something. He writes That is called UTF-1

Re: Subject Unicode

On Fri, 10 Jan 2014 09:36:32 -0500, Harry Wahl wrote: > >... Windows Notepad is particularly tricky because it adds them without you >realizing it. So whether you look at a file with Notepad (or other simple >editor) or don't can both affect your results and cause you to question your >sanity be

Re: Subject Unicode

Date: Fri, 10 Jan 2014 08:01:42 + > From: peter.hunke...@credit-suisse.com > Subject: Re: Subject Unicode > To: IBM-MAIN@LISTSERV.UA.EDU > > >Other than with a lot of inferential cleverness, there is no way to look at > >an "ASCII-like" file and tell what th

Re: Subject Unicode

On Thu, 9 Jan 2014 22:44:19 -0500, Don Poitras wrote: >As of z/OS 2.1, ISPF supports UTF-8, so a binary transfer will still show an A >if it >was an A on the PC. ... > Does this support both UNIX and legacy files? If the latter, does it require RECFM=V? Using a variable-length character encodi

Re: Subject Unicode

>Other than with a lot of inferential cleverness, there is no way to look at an >"ASCII-like" file and tell what the code page is. The same applies to data encoded in EBCDIC. In fact, files are nothing but a series of bytes. You always need to know what those byes represent in order to be able

Re: Subject Unicode

Charles Mills writes: >You could use 16 bits for every character, with some sort of >cleverness that yielded two 16-bit words when you had a code >point bigger than 65535 (actually somewhat less due to how the >cleverness works). That is called UTF-16. Pretty good but >still not very efficient. In

Re: Subject Unicode

Yup. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Thursday, January 09, 2014 8:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode At 17:45 -0800 on 01/09/2014, Charles Mills wrote

Re: Subject Unicode

At 17:45 -0800 on 01/09/2014, Charles Mills wrote about Re: Subject Unicode: You could use 8 bits for most characters, with cleverness that expanded that out to two or three bytes for more obscure characters. Pretty efficient, and you could make the first part of the character set the same

Re: Subject Unicode

al Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Scott Ford > Sent: Thursday, January 09, 2014 5:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Subject Unicode > > Gil, > > We send a data message from a pc, we

Re: Subject Unicode

ISPF and most COBOL programs expect. > Comprende? > Charles > -Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Scott Ford > Sent: Thursday, January 09, 2014 4:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject:

Re: Subject Unicode

On 9 January 2014 20:39, Scott Ford wrote: > We send a data message from a pc, we encrypt it with AES128 , the message is > received at the host (z/OS) decrypted then converted from ascii to ebcdic..so > I am trying to figure out how to > Determine what codepage the pc uses and have z/OS convert

Re: Subject Unicode

RV.UA.EDU] On Behalf Of Scott Ford Sent: Thursday, January 09, 2014 5:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Subject Unicode Gil, We send a data message from a pc, we encrypt it with AES128 , the message is received at the host (z/OS) decrypted then converted from ascii to ebcdic..so I

Re: Subject Unicode

Scott - The PC is going to have to provide the codepage of the message data someplace in the communication protocol. Either as a separate field, separate message or as a prefix/suffix to the message data. It will be pretty dicey to attempt to guess the codepage based on the message data. One oth

Re: Subject Unicode

Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Thursday, January 09, 2014 4:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Subject Unicode All: I have a fundamental question on Unicode, or more of how it works . I am confused about the following scenario.. PC ( d

Re: Subject Unicode

Gil, We send a data message from a pc, we encrypt it with AES128 , the message is received at the host (z/OS) decrypted then converted from ascii to ebcdic..so I am trying to figure out how to Determine what codepage the pc uses and have z/OS convert it to the proper EBCDIC codepage from ASCII.

Re: Subject Unicode

On Thu, 9 Jan 2014 16:35:55 -0800, Scott Ford wrote: >All: � I have a fundamental question on Unicode, or more of how it works . I am confused about the following scenario.. PC ( data using a foreign language Unicode page, like French )� going to z/OS and being keep in tact. Names and addres

Subject Unicode

All:   I have a fundamental question on Unicode, or more of how it works . I am confused about the following scenario.. PC ( data using a foreign language Unicode page, like French )  going to z/OS and being keep in tact. Names and address type data. As the application do I have to query the