Re: UTF16 to EBCDIC

[Seymour J Metz]

AFAIK every IBM operating system for the z architecture uses EBCDIC.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Adam Jacobvitz <02b29b762ea6-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 10, 2020 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

IBM mainframes still use EBCDIC?

On Mon, Feb 10, 2020 at 10:54 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:
>
>>Why wasn't it simple matter of replacing "colon" with ":" and removing the 
>>spaces?
>>
> My fingers betrayed me and deleted one character too many.
>
> I find "roboprig" overly generous; I'd call this software a robovandal. I'm 
> getting broadband at home, and am curious whether it is just the webmail or 
> the mail server that is rewriting message text. Depending on the answer, I 
> may start using a different e-mail address, assuming that Verizon isn't 
> playing the same games.
>>
> That way they can track not only you but me. Actually, robomole.
>
> 
> From: Paul Gilmartin
> Sent: Friday, February 7, 2020 2:48 PM
>
>>Have you read https colon 
>>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
>> What are your source and target CCIDs?
>>
> I had difficulty repairing your desperate attempt to circumvent a roboprig. 
> Perhaps:
> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf
>
> -- 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: UTF16 to EBCDIC

[Seymour J Metz]

It was no easier to used existing 6-bit peripherals with EBCDIC than it would 
have been with ASCII, and it was no easier to use the 8-bit peripherals either.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Monday, February 10, 2020 4:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

ASCII wasn't finalized when the S/360 was announced.  And it needed to
use existing 7 bit peripherals, tapes, etc.

On Mon, Feb 10, 2020 at 1:27 PM Adam Jacobvitz
<02b29b762ea6-dmarc-requ...@listserv.ua.edu> wrote:
>
> IBM mainframes still use EBCDIC?
>
> On Mon, Feb 10, 2020 at 10:54 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:
> >
> >>Why wasn't it simple matter of replacing "colon" with ":" and removing the 
> >>spaces?
> >>
> > My fingers betrayed me and deleted one character too many.
> >
> > I find "roboprig" overly generous; I'd call this software a robovandal. I'm 
> > getting broadband at home, and am curious whether it is just the webmail or 
> > the mail server that is rewriting message text. Depending on the answer, I 
> > may start using a different e-mail address, assuming that Verizon isn't 
> > playing the same games.
> >>
> > That way they can track not only you but me. Actually, robomole.
> >
> > 
> > From: Paul Gilmartin
> > Sent: Friday, February 7, 2020 2:48 PM
> >
> >>Have you read https colon 
> >>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
> >> What are your source and target CCIDs?
> >>
> > I had difficulty repairing your desperate attempt to circumvent a roboprig. 
> > Perhaps:
> > https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf
> >
> > -- 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



--
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: UTF16 to EBCDIC

[Seymour J Metz]

It controlled the generation, checking and use of zones in packed decimal data. 
Basically it affected only UNPK and decimal arithmetic.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Monday, February 10, 2020 5:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

I heard about that bit in college.  Do you know what it was supposed to
do internally?

On 2/10/2020 1:50 PM, Pew, Curtis G wrote:
> On Feb 10, 2020, at 3:01 PM, Mike Schwab  wrote:
>>
>> ASCII wasn't finalized when the S/360 was announced.  And it needed to
>> use existing 7 bit peripherals, tapes, etc.
>>
>
> But System/360 was supposed to be an ASCII machine, or at least to transition 
> to ASCII long term. There was a bit in the PSW to determine if ASCII was in 
> use or not. The IBM engineers, programmers, lower-level managers, and 
> *customers* didn’t understand the importance of it, though, so it never 
> happened. In System/360 the ASCII bit was repurposed to switch between EC 
> mode (needed for DAT) and BC mode.
>
> Today those of us who use z/OS, etc. are paying the price for that lack of 
> vision.
>
>

--
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: UTF16 to EBCDIC

[Seymour J Metz]

There are a few missing data there.

First, there is the issue of the dualing of a couple of ASCII code points.

Second, while ANSI did define an ASCII-8 standard for punched cards, it didn't 
actually assign any code pages in the upper half. IBM had to guess at ANSI's 
direction for ASCII-8, and guessed wrong.

Third, EBCDIC didn't have the same collating sequence as any of the 6-bit BCD 
codes.

Fourth, there was no technical reason that IBM couldn't use existing 
peripherals and translate character sets in software.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 10, 2020 5:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

On Mon, 10 Feb 2020 21:50:59 +, Pew, Curtis G wrote:

>On Feb 10, 2020, at 3:01 PM, Mike Schwab wrote:
>>
>> ASCII wasn't finalized when the S/360 was announced.  And it needed to
>> use existing 7 bit peripherals, tapes, etc.
>
>But System/360 was pupposed to be an ASCII machine, or at least to transition 
>to ASCII long term. There was a bit in the PSW to determine if ASCII was in 
>use or not. The IBM engineers, programmers, lower-level managers, and 
>*customers* didn’t understand the importance of it, though, so it never 
>happened. In System/360 the ASCII bit was repurposed to switch between EC mode 
>(needed for DAT) and BC mode.
>
>Today those of us who use z/OS, etc. are paying the price for that lack of 
>vision.
>
+1.  The late Bob Bemer with impressive credentials argued compellingly:

https://secure-web.cisco.com/1pZnzDmGlFNCqW-nXOw_EcOssIHtWbElWN-baqOsG2fTedLsKE_no_RBtwEh-lozUoDvPFnhWIE_tL0CqnF7yd2xSM_jSiZuopskeH1ZF35ExhKYc3FSl4x_rfBpXFG3l4tazGWnJU4Bv-b3iFv5KTpqrgO2MokhBKdPd0Z6x32fph8dRmQbwBgqwicIGdwEKTfJ0hS1SAlZClVKhW8V6cdCFlpGQAtJyDY19nEDyoXDCMnIuUH-jUU197g6RUgzszTNfrGNfHm5ylBWP2iMSy7UZCyrq8Sb4VIm4CXKNYKMxG9ZlshjWe2XsT3xTYtKrE2e0nAn3-sfNSisffX9kfUdqQef32L5lPSvUPy-kERbqawEiA9ya7HtSXB1ye2OhsCN4Gfpvcggvm3HgpIi-NwVZ8ywyDsj8IItN75PqdYtKvxxPRm85WdIKfGyiru7n/https%3A%2F%2Fweb.archive.org%2Fweb%2F20180513204153%2Fhttp%3A%2F%2Fwww.bobbemer.com%2FP-BIT.HTM

... that ASCII was ready; IBM wasn't.

-- 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: UTF16 to EBCDIC

[Seymour J Metz]

Note that an EBCDIC DEL is 07.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Bill Godfrey 
Sent: Monday, February 10, 2020 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

On Mon, 10 Feb 2020 12:21:58 -0600, Paul Gilmartin  wrote:

>On Mon, 10 Feb 2020 07:58:26 -0600, Bill Godfrey wrote:
>
>>Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:
>>
>>>od -tx1 -An utf16.txt
>>00  28  20  1C  00  61  20  1D  00  29  00  0A
>>
>>U+0028 is left parenthesis
>>U+201C is left double quotation mark
>>U+0061 is small letter "a"
>>U+201D is right double quotation mark
>>U+0029 is right parenthesis
>>
>>There are no correstponding quotation marks in EBCDIC 1047.
>>The iconv command converts them to hex 3F.
>>
>>>iconv -f 1200 -t ibm-1047 >4D  3F  81  3F  5D  15
>> ( 077   a 077   )  \n
>>
>I submitted an RCF a couple days ago.  This should be documented.
>
>Hex 3F is SUBstitute, intended as a substitute for untranslatable
>characters.  Good.  If the target code page is ASCII-based, does it
>produce the corresponding hex 1A?  It should despite the risk that
>CP/M (and old MS-DOS?) misused SUB as end-of-text-file.

Hex 1A for iso8859-1, but 7F for 437.

$ iconv -f 1200 -t iso8859-1 

Re: UTF16 to EBCDIC

[Bill Godfrey]

On Mon, 10 Feb 2020 12:21:58 -0600, Paul Gilmartin  wrote:

>On Mon, 10 Feb 2020 07:58:26 -0600, Bill Godfrey wrote:
>
>>Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:
>>
>>>od -tx1 -An utf16.txt
>>00  28  20  1C  00  61  20  1D  00  29  00  0A
>>
>>U+0028 is left parenthesis
>>U+201C is left double quotation mark
>>U+0061 is small letter "a"
>>U+201D is right double quotation mark
>>U+0029 is right parenthesis
>>
>>There are no correstponding quotation marks in EBCDIC 1047.
>>The iconv command converts them to hex 3F.
>>
>>>iconv -f 1200 -t ibm-1047 >4D  3F  81  3F  5D  15
>> ( 077   a 077   )  \n
>>
>I submitted an RCF a couple days ago.  This should be documented.
>
>Hex 3F is SUBstitute, intended as a substitute for untranslatable
>characters.  Good.  If the target code page is ASCII-based, does it
>produce the corresponding hex 1A?  It should despite the risk that
>CP/M (and old MS-DOS?) misused SUB as end-of-text-file.

Hex 1A for iso8859-1, but 7F for 437.

$ iconv -f 1200 -t iso8859-1 

Re: UTF16 to EBCDIC

[Tom Brennan]

Thanks, that makes sense.

On 2/10/2020 2:23 PM, Mike Schwab wrote:

Decimal instructions were affected.  Character sets didn't really
affect other instructions.

On Mon, Feb 10, 2020 at 4:17 PM Tom Brennan  wrote:


I heard about that bit in college.  Do you know what it was supposed to
do internally?

On 2/10/2020 1:50 PM, Pew, Curtis G wrote:

On Feb 10, 2020, at 3:01 PM, Mike Schwab  wrote:


ASCII wasn't finalized when the S/360 was announced.  And it needed to
use existing 7 bit peripherals, tapes, etc.



But System/360 was supposed to be an ASCII machine, or at least to transition 
to ASCII long term. There was a bit in the PSW to determine if ASCII was in use 
or not. The IBM engineers, programmers, lower-level managers, and *customers* 
didn’t understand the importance of it, though, so it never happened. In 
System/360 the ASCII bit was repurposed to switch between EC mode (needed for 
DAT) and BC mode.

Today those of us who use z/OS, etc. are paying the price for that lack of 
vision.




--
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: UTF16 to EBCDIC

[Mike Schwab]

Decimal instructions were affected.  Character sets didn't really
affect other instructions.

On Mon, Feb 10, 2020 at 4:17 PM Tom Brennan  wrote:
>
> I heard about that bit in college.  Do you know what it was supposed to
> do internally?
>
> On 2/10/2020 1:50 PM, Pew, Curtis G wrote:
> > On Feb 10, 2020, at 3:01 PM, Mike Schwab  wrote:
> >>
> >> ASCII wasn't finalized when the S/360 was announced.  And it needed to
> >> use existing 7 bit peripherals, tapes, etc.
> >>
> >
> > But System/360 was supposed to be an ASCII machine, or at least to 
> > transition to ASCII long term. There was a bit in the PSW to determine if 
> > ASCII was in use or not. The IBM engineers, programmers, lower-level 
> > managers, and *customers* didn’t understand the importance of it, though, 
> > so it never happened. In System/360 the ASCII bit was repurposed to switch 
> > between EC mode (needed for DAT) and BC mode.
> >
> > Today those of us who use z/OS, etc. are paying the price for that lack of 
> > vision.
> >
> >
>
> --
> 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

Re: UTF16 to EBCDIC

[Tom Brennan]

I heard about that bit in college.  Do you know what it was supposed to 
do internally?


On 2/10/2020 1:50 PM, Pew, Curtis G wrote:

On Feb 10, 2020, at 3:01 PM, Mike Schwab  wrote:


ASCII wasn't finalized when the S/360 was announced.  And it needed to
use existing 7 bit peripherals, tapes, etc.



But System/360 was supposed to be an ASCII machine, or at least to transition 
to ASCII long term. There was a bit in the PSW to determine if ASCII was in use 
or not. The IBM engineers, programmers, lower-level managers, and *customers* 
didn’t understand the importance of it, though, so it never happened. In 
System/360 the ASCII bit was repurposed to switch between EC mode (needed for 
DAT) and BC mode.

Today those of us who use z/OS, etc. are paying the price for that lack of 
vision.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Mon, 10 Feb 2020 21:50:59 +, Pew, Curtis G wrote:

>On Feb 10, 2020, at 3:01 PM, Mike Schwab wrote:
>> 
>> ASCII wasn't finalized when the S/360 was announced.  And it needed to
>> use existing 7 bit peripherals, tapes, etc.
>
>But System/360 was pupposed to be an ASCII machine, or at least to transition 
>to ASCII long term. There was a bit in the PSW to determine if ASCII was in 
>use or not. The IBM engineers, programmers, lower-level managers, and 
>*customers* didn’t understand the importance of it, though, so it never 
>happened. In System/360 the ASCII bit was repurposed to switch between EC mode 
>(needed for DAT) and BC mode.
>
>Today those of us who use z/OS, etc. are paying the price for that lack of 
>vision.
>
+1.  The late Bob Bemer with impressive credentials argued compellingly:
https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-BIT.HTM

... that ASCII was ready; IBM wasn't.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Pew, Curtis G]

On Feb 10, 2020, at 3:01 PM, Mike Schwab  wrote:
> 
> ASCII wasn't finalized when the S/360 was announced.  And it needed to
> use existing 7 bit peripherals, tapes, etc.
> 

But System/360 was supposed to be an ASCII machine, or at least to transition 
to ASCII long term. There was a bit in the PSW to determine if ASCII was in use 
or not. The IBM engineers, programmers, lower-level managers, and *customers* 
didn’t understand the importance of it, though, so it never happened. In 
System/360 the ASCII bit was repurposed to switch between EC mode (needed for 
DAT) and BC mode.

Today those of us who use z/OS, etc. are paying the price for that lack of 
vision.


-- 
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: UTF16 to EBCDIC

[Mike Schwab]

ASCII wasn't finalized when the S/360 was announced.  And it needed to
use existing 7 bit peripherals, tapes, etc.

On Mon, Feb 10, 2020 at 1:27 PM Adam Jacobvitz
<02b29b762ea6-dmarc-requ...@listserv.ua.edu> wrote:
>
> IBM mainframes still use EBCDIC?
>
> On Mon, Feb 10, 2020 at 10:54 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:
> >
> >>Why wasn't it simple matter of replacing "colon" with ":" and removing the 
> >>spaces?
> >>
> > My fingers betrayed me and deleted one character too many.
> >
> > I find "roboprig" overly generous; I'd call this software a robovandal. I'm 
> > getting broadband at home, and am curious whether it is just the webmail or 
> > the mail server that is rewriting message text. Depending on the answer, I 
> > may start using a different e-mail address, assuming that Verizon isn't 
> > playing the same games.
> >>
> > That way they can track not only you but me. Actually, robomole.
> >
> > 
> > From: Paul Gilmartin
> > Sent: Friday, February 7, 2020 2:48 PM
> >
> >>Have you read https colon 
> >>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
> >> What are your source and target CCIDs?
> >>
> > I had difficulty repairing your desperate attempt to circumvent a roboprig. 
> > Perhaps:
> > https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf
> >
> > -- 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



-- 
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

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Mon, 10 Feb 2020 19:26:46 +, Adam Jacobvitz wrote:

>IBM mainframes still use EBCDIC?
>
EBCDIC and Fixed-80 are among the bituminous progeny of the
unholy union of OS/360 and the 029 keypunch.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Adam Jacobvitz]

IBM mainframes still use EBCDIC?

On Mon, Feb 10, 2020 at 10:54 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:
>
>>Why wasn't it simple matter of replacing "colon" with ":" and removing the 
>>spaces?
>>
> My fingers betrayed me and deleted one character too many.
>
> I find "roboprig" overly generous; I'd call this software a robovandal. I'm 
> getting broadband at home, and am curious whether it is just the webmail or 
> the mail server that is rewriting message text. Depending on the answer, I 
> may start using a different e-mail address, assuming that Verizon isn't 
> playing the same games.
>>
> That way they can track not only you but me. Actually, robomole.
>
> 
> From: Paul Gilmartin
> Sent: Friday, February 7, 2020 2:48 PM
>
>>Have you read https colon 
>>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
>> What are your source and target CCIDs?
>>
> I had difficulty repairing your desperate attempt to circumvent a roboprig. 
> Perhaps:
> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf
>
> -- 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: UTF16 to EBCDIC

[Paul Gilmartin]

On Mon, 10 Feb 2020 18:43:32 +, Seymour J Metz wrote:

>Why wasn't it  simple matter of replacing "colon" with ":" and removing the 
>spaces? 
>
My fingers betrayed me and deleted one character too many.

I find "roboprig" overly generous; I'd call this software a robovandal. I'm 
getting broadband at home, and am curious whether it is just the webmail or the 
mail server that is rewriting message text. Depending on the answer, I may 
start using a different e-mail address, assuming that Verizon isn't playing the 
same games.
>
That way they can track not only you but me.  Actually, robomole.


From:  Paul Gilmartin
Sent: Friday, February 7, 2020 2:48 PM

>Have you read https colon 
>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
> What are your source and target CCIDs?
>
I had difficulty repairing your desperate attempt to circumvent a roboprig.  
Perhaps:

https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Seymour J Metz]

Why wasn't it  simple matter of replacing "colon" with ":" and removing the 
spaces? I find "roboprig" overly generous; I'd call this software a robovandal. 
I'm getting broadband at home, and am curious whether it is just the webmail or 
the mail server that is rewriting message text. Depending on the answer, I may 
start using a different e-mail address, assuming that Verizon isn't playing the 
same games.

Yes, I meant code pages.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 7, 2020 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

On Fri, 7 Feb 2020 19:17:30 +, Seymour J Metz wrote:

>Have you read https colon 
>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
> What are your source and target CCIDs?
>
I had difficulty repairing your desperate attempt to circumvent a roboprig.  
Perhaps:

https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf

>Note that EBCDIC is a family of code points and UTF16 is a Unicode transform;
  ^^
ITYM "code pages" or "CCSIDs".

> ... neither identifies a single character set. In particular, IBM supports 
> both the current Unicode and some older versions.

Well said.


From: Jake Anderson
Sent: Thursday, February 6, 2020 9:29 PM

I am looking way to translate from UTF16 to EBCDIC. When I do D UNI,ALL i
do not see UTF16 to EBCDIC conversion table.

Is it something I need to load as CUNIMG or I have to create a table then
refer them while FTP ing ?

-- 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: UTF16 to EBCDIC

[Paul Gilmartin]

On Mon, 10 Feb 2020 07:58:26 -0600, Bill Godfrey wrote:

>Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:
>
>>od -tx1 -An utf16.txt
>00  28  20  1C  00  61  20  1D  00  29  00  0A
>
>U+0028 is left parenthesis
>U+201C is left double quotation mark
>U+0061 is small letter "a"
>U+201D is right double quotation mark
>U+0029 is right parenthesis
>
>There are no correstponding quotation marks in EBCDIC 1047.
>The iconv command converts them to hex 3F.
>
>>iconv -f 1200 -t ibm-1047 4D  3F  81  3F  5D  15
> ( 077   a 077   )  \n
>
I submitted an RCF a couple days ago.  This should be documented.

Hex 3F is SUBstitute, intended as a substitute for untranslatable
characters.  Good.  If the target code page is ASCII-based, does it
produce the corresponding hex 1A?  It should despite the risk that
CP/M (and old MS-DOS?) misused SUB as end-of-text-file.

POSIX leaves the effect of errors implementation defined.

Tests on MacOS and Linux produce chaotic results, symptomatic
of bugs in their iconv utilities.  Linux seems to require BOM with
UTF-16.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Sun, 9 Feb 2020 23:39:38 -0600, Mike Schwab wrote:

>EBCDIC, EBCDIC DBCS, UTF-16, and ASCII all require the user to know
>the code page for the data set.  ... 
>
Practically, no.  A typical modern system has a ubiquitous default
Unicode page and most editors, shells, interpreters, compilers,
and utilities are savvy to this to the extent necessary.  This is
transparent to a naive user and welcomed by a sophisticated user,

So:
682 $ echo "'uname -s'; say '$LANG: Привет שָׁלוֹם bonjour'" | tee foo
'uname -s'; say 'en_US.UTF-8: Привет שָׁלוֹם bonjour'
683 $ 
683 $ rexx foo
Darwin
en_US.UTF-8: Привет שָׁלוֹם bonjour


Difficulties arise with format specifications.

Full disclosure: I didn't get my sample right on the first try.  But it
would have been harder with DBCS, TSO READY prompt, and COBOL.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Seymour J Metz]

DBCS is not Unicode.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Edward Finnell <000248cce9f3-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, February 9, 2020 11:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

Guess I don't see the reasoning. IBM has had DBCS for decades.

http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In a message 
dated 2/9/2020 9:58:05 PM Central Standard Time, li...@akphs.com writes:
Gil corrected me:
> You're describing UTF-8.  UTF-16 uses 16-bit code units.>    
> <https://secure-web.cisco.com/1PeL2cTXF3BBwd_GnilnC9q2Z60S_ytn4x_k3psCTeWwm_PQf2DXNJ1j-6goTziinIaUEHr2cfQ5DX7YT4SsuA4J-kwXx8oE5DmKNu5HazAlZJ76hLJOpiDegzLq5ZirlP_Buv_YIL6nsunY40wP0ch24SfUSYpR4DrWw030gvSFBa79wPsxHpAj8Azw7E9uIUDwW6kr0ZqSrBrTNBxOADVwSzy9BkdvvhTaR6ZaK5tGFhcRNRwB4P5PMB8AR5MrqXegw0io9tVy3hpObFIno5AGVfoiXpl0Y3no5h6V4ZGl4gs319zcd698XQzvTLDLc6QcbvQylm9fcghq9x9vXbrWyU8lqb0qGTMWiWCIPYVOpxlvUxltvMMtsxGKMvhuqQ2zwdd9E8jVflzDUAS27lsNhNVN1gg2u7DtGh2q92odr3t7nWBLzeGhhRL9Pe9ZF/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-16>
>  
> https://secure-web.cisco.com/1PeL2cTXF3BBwd_GnilnC9q2Z60S_ytn4x_k3psCTeWwm_PQf2DXNJ1j-6goTziinIaUEHr2cfQ5DX7YT4SsuA4J-kwXx8oE5DmKNu5HazAlZJ76hLJOpiDegzLq5ZirlP_Buv_YIL6nsunY40wP0ch24SfUSYpR4DrWw030gvSFBa79wPsxHpAj8Azw7E9uIUDwW6kr0ZqSrBrTNBxOADVwSzy9BkdvvhTaR6ZaK5tGFhcRNRwB4P5PMB8AR5MrqXegw0io9tVy3hpObFIno5AGVfoiXpl0Y3no5h6V4ZGl4gs319zcd698XQzvTLDLc6QcbvQylm9fcghq9x9vXbrWyU8lqb0qGTMWiWCIPYVOpxlvUxltvMMtsxGKMvhuqQ2zwdd9E8jVflzDUAS27lsNhNVN1gg2u7DtGh2q92odr3t7nWBLzeGhhRL9Pe9ZF/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-16


Jeez, yes, of course. Brainfart! Thanks.

--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: UTF16 to EBCDIC

[Seymour J Metz]

All talk about *anything* you don't understand is potentially dangerous. 
Typically people blow away critical distinctions until they have been burned. 
Experience keeps a dear school.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Sunday, February 9, 2020 11:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

*ALL* talk about Unicode is dangerous ;-).  Your description is of UTF-8,
which can use 1, 2, 3, or 4 bytes per character, while UTF-16 uses only
either 2 or 4.  Both are variable-length encoding, although the variability
of UTF-16 is... strange.

sas


On Sun, Feb 9, 2020 at 9:51 PM Phil Smith III  wrote:

> Mike Schwab wrote:
>
> >Would UTF-16 to UTF-8 be a better conversion?  You still have to be
>
> >certain of the source character set.  And is supported by some z/OS
>
> >software.
>
>
>
> As Cameron indicated, your comment doesn't quite make sense. UTF-16 is
> just a variable-length encoding, in which basic ASCII*
> (0-127) are single-byte, some characters are two-byte, some three-, and
> some four-. More efficient, especially in the "mostly basic
> ASCII" case.
>
>
>
> *Yes, I know, talking about "ASCII" in the context of Unicode is dangerous
> and arguably incorrect. You know what I mean.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
sas

--
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: UTF16 to EBCDIC

[Seymour J Metz]

Those all relate to Unicode, not to EBCDIC DBCS.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, February 9, 2020 11:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

On Mon, 10 Feb 2020 04:06:35 +, Edward Finnell < wrote:

>Guess I don't see the reasoning. IBM has had DBCS for decades.
>
>http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In
ITYM:
 http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1


>> You're describing UTF-8.  UTF-16 uses 16-bit code units.>    
>> <https://secure-web.cisco.com/1Htvvwl1WZ2TEOgclMX3fmDXN0J5lneSa_-0iAUgaZbjWrifC2jVJupiVOPtEcAGXsMQi_q1t-4h2AkQ-NTuQCF8BYOTN3Ffdr3HDqYqvfXy4Jy7vbz7j_xAq72QRW33b6fojIwihBkLQ0Yppw4P8zq396PPMXrldXgtKig36DC6wsrGUaGAgWJdRUyXeMb2kjrH_DNGZYERJwHvX1HThsAnc-kq9Q6f9BBO-acoKHehJzJIBHEwgD9za8n9DyF7BQE4vdPlJtCKaqwHI2sQPnYOtwRoZTSWBEdNs91pLKVtqB8S_JVw9MBZD8HZ-htsfcqktylxFnyDPRi9UeCWZCm_xdqZV5O5T_uVikrsURSkz5TgYpfwbAwv_QsSf0lvszBTjhGTMWKjc28IAzzb-2i7Jol50ZG53sAG-4-tWZ0byVaDpt8MinxVtBEVmLLdM/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-16>
>>  
>> https://secure-web.cisco.com/1Htvvwl1WZ2TEOgclMX3fmDXN0J5lneSa_-0iAUgaZbjWrifC2jVJupiVOPtEcAGXsMQi_q1t-4h2AkQ-NTuQCF8BYOTN3Ffdr3HDqYqvfXy4Jy7vbz7j_xAq72QRW33b6fojIwihBkLQ0Yppw4P8zq396PPMXrldXgtKig36DC6wsrGUaGAgWJdRUyXeMb2kjrH_DNGZYERJwHvX1HThsAnc-kq9Q6f9BBO-acoKHehJzJIBHEwgD9za8n9DyF7BQE4vdPlJtCKaqwHI2sQPnYOtwRoZTSWBEdNs91pLKVtqB8S_JVw9MBZD8HZ-htsfcqktylxFnyDPRi9UeCWZCm_xdqZV5O5T_uVikrsURSkz5TgYpfwbAwv_QsSf0lvszBTjhGTMWKjc28IAzzb-2i7Jol50ZG53sAG-4-tWZ0byVaDpt8MinxVtBEVmLLdM/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-16
>
>
>Jeez, yes, of course. Brainfart! Thanks.
>
>--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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Don Poitras]

Be careful _which_ utf-16 you've got. This example is "big-endian". If you do a 
binary
copy of a file from Windows it's going to be "little-endian" and you need to do 
the 
iconv using 1202 instead of 1200.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.cunu100/uniccsi.htm


In article <7673993116478651.wa.bgodfrey.gzgmail@listserv.ua.edu> you wrote:
> Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:

> >od -tx1 -An utf16.txt
> 00  28  20  1C  00  61  20  1D  00  29  00  0A

> U+0028 is left parenthesis
> U+201C is left double quotation mark
> U+0061 is small letter "a"
> U+201D is right double quotation mark
> U+0029 is right parenthesis

> There are no correstponding quotation marks in EBCDIC 1047.
> The iconv command converts them to hex 3F.

> >iconv -f 1200 -t ibm-1047  4D  3F  81  3F  5D  15
>  ( 077   a 077   )  \n

> The EDCICONV program, using data sets, produces the same results, with return 
> code 0 and no message.

> Bill

> On Sat, 8 Feb 2020 16:44:50 -0600, Paul Gilmartin  
> wrote:

> >On Sat, 8 Feb 2020 16:31:56 -0500, Phil Smith III wrote:
> >>
> >>>How does it handle characters absent from IBM-037?
> >>
> >>I expect it will throw an error. This is, as you (Gil) know, one of the 
> >>problems with OP???s query: you can???t stuff thousands of pounds of 
> >>potatoes into a 256-pound sack. (OK, characters, not potatoes.)  ...
> >>
> >The Command Ref. says:
> >If the input contains a character that is not valid in the destination 
> > code set, behavior
> >depends on the system's iconv() function. See z/OS XL C/C++ Runtime 
> > Library Reference
> >for more information about the character that is used for converting 
> > incorrect characters.
> >Which says:
> >If iconv() encounters a character in the input buffer that is valid, but 
> > for which
> >a conversion is not defined in the conversion descriptor, cd, then 
> > iconv() performs
> >a nonidentical conversion on this character. The conversion is 
> > implementation-defined.
> >
> >But no indication that it throws an error.  Of course the iconv utility 
> >could check
> >the output of iconv() and report its own error.
> >
> >"implementation-defined"?  This is the document that's supposed to provide 
> >that
> >definition.  I'll submit an RCF.  And a minor one.  "nonidentical" is 
> >invented nonsense.
> >the correct term is "injective:"  
> >https://en.wikipedia.org/wiki/Injective_function
> >
> >> ...
> >>>I wonder what was the motivation to require preallocated data set
> >>>names rather than the more flexible alternative of DDNAMEs?
> >>
> >>I believe it???s using ICONV on the USS side under the covers, which takes 
> >>a data set name.
> >> 
> >Appendix K of the Command Ref. does not list iconv as among the
> >utilities that accept data set names.  Of course, IBM is allowed to use
> >non-GUPI interfaces internally.
> >
> >-- gil

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Seymour J Metz]

ASCII is a subset of Unicode, and the UTF-8 transform of an ASCII code point is 
that code point, so I'd say total upward compatibility. Of course, ASCII had 
compatibility issues with itself in the early days, with some bizarre dualing 
of code points.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, February 9, 2020 11:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

On Mon, 10 Feb 2020 04:06:35 +, Edward Finnell < wrote:

>Guess I don't see the reasoning. IBM has had DBCS for decades.
>
>http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In
ITYM:
 http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1

UTF-8 has enormous compatibility with ASCII.  IBM DBCS has such
compatibility neither with EBCDIC nor with ASCII.  On Linux or MacOS
I can code C source programs or shell scripts alike in ASCII or UTF-8.
Can COBOL or HLASM source, or JCL be DBCS?

-- 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: UTF16 to EBCDIC

[Seymour J Metz]

Not quite.

There are multiple EBCDIC code pages and multiple EBCDIC code pages, but ASCII 
is a single 7-bit character set. There are multiple code pages that match ASCII 
at 0-127 or a proper subset of that, e.g., 437, 850, 8859-*.

UTF-16 is a transform of Unicode, encoding 20-bit bytes using 16-bit bytes or 
pairs of them. The different code pages indicate the order of the 8-bit bytes 
within the 16-bit bytes; all else is the same.

UTF-8 is also a Unicode transform, and includes the same characters as UTF-16. 
There are characters not included in Unicode, but I don't know of any sch that 
are in an EBCDIC code page.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Monday, February 10, 2020 12:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF16 to EBCDIC

EBCDIC, EBCDIC DBCS, UTF-16, and ASCII all require the user to know
the code page for the data set.  UTF-8 uses up to 32 bits and
incorporates all languages include several DBCS languages from Asia.

On Sun, Feb 9, 2020 at 10:07 PM Edward Finnell
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>
> Guess I don't see the reasoning. IBM has had DBCS for decades.
>
> http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In a message 
> dated 2/9/2020 9:58:05 PM Central Standard Time, li...@akphs.com writes:
> Gil corrected me:
> > You're describing UTF-8.  UTF-16 uses 16-bit code units.>
> > <https://secure-web.cisco.com/1ojCKog3IUmOhFh11CUwi9vf_AgUpgX8sIzXKSn-8YTxA7f75d-vQoq_6dpvz2XBV3Yx0KIEZcWprUg7jedflPFBvEXnvce1ZR8Uh0NXFCuWfGIa-dXRxqi2XM_fdzqhtaxSgeMFzhwrNkrcOQeko1ZjbozzYndx3DjPuy3BaOrGUa8VCt0Ja3nMKAjOrfc-zuZqIYMcD7VABm6T5-pGqgoMPk-0e6AaRdwPkS_yxJugErPeswls26xnC_AQD75pmpdZXGh4s6aDfZzUFz2lHZxZVeotE4mjD-5Yp_MbtKr-mqHJax5BotApPTmfpLuAL6ijxkHXu7f9-NKcPUigeYvL0j7afL8zyczwXAkqi5JP6LNc1Jjkn7XB4I9RcfQed/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-16>
> >  
> > https://secure-web.cisco.com/1ojCKog3IUmOhFh11CUwi9vf_AgUpgX8sIzXKSn-8YTxA7f75d-vQoq_6dpvz2XBV3Yx0KIEZcWprUg7jedflPFBvEXnvce1ZR8Uh0NXFCuWfGIa-dXRxqi2XM_fdzqhtaxSgeMFzhwrNkrcOQeko1ZjbozzYndx3DjPuy3BaOrGUa8VCt0Ja3nMKAjOrfc-zuZqIYMcD7VABm6T5-pGqgoMPk-0e6AaRdwPkS_yxJugErPeswls26xnC_AQD75pmpdZXGh4s6aDfZzUFz2lHZxZVeotE4mjD-5Yp_MbtKr-mqHJax5BotApPTmfpLuAL6ijxkHXu7f9-NKcPUigeYvL0j7afL8zyczwXAkqi5JP6LNc1Jjkn7XB4I9RcfQed/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FUTF-16
>
>
> Jeez, yes, of course. Brainfart! Thanks.
>
> --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



--
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: UTF16 to EBCDIC

[Bill Godfrey]

Given a USS file utf16.txt containing 6 UTF-16 characters, 12 bytes:

>od -tx1 -An utf16.txt
00  28  20  1C  00  61  20  1D  00  29  00  0A

U+0028 is left parenthesis
U+201C is left double quotation mark
U+0061 is small letter "a"
U+201D is right double quotation mark
U+0029 is right parenthesis

There are no correstponding quotation marks in EBCDIC 1047.
The iconv command converts them to hex 3F.

>iconv -f 1200 -t ibm-1047  wrote:

>On Sat, 8 Feb 2020 16:31:56 -0500, Phil Smith III wrote:
>>
>>>How does it handle characters absent from IBM-037?
>>
>>I expect it will throw an error. This is, as you (Gil) know, one of the 
>>problems with OP’s query: you can’t stuff thousands of pounds of potatoes 
>>into a 256-pound sack. (OK, characters, not potatoes.)  ...
>>
>The Command Ref. says:
>If the input contains a character that is not valid in the destination 
> code set, behavior
>depends on the system's iconv() function. See z/OS XL C/C++ Runtime 
> Library Reference
>for more information about the character that is used for converting 
> incorrect characters.
>Which says:
>If iconv() encounters a character in the input buffer that is valid, but 
> for which
>a conversion is not defined in the conversion descriptor, cd, then iconv() 
> performs
>a nonidentical conversion on this character. The conversion is 
> implementation-defined.
>
>But no indication that it throws an error.  Of course the iconv utility could 
>check
>the output of iconv() and report its own error.
>
>"implementation-defined"?  This is the document that's supposed to provide that
>definition.  I'll submit an RCF.  And a minor one.  "nonidentical" is invented 
>nonsense.
>the correct term is "injective:"  
>https://en.wikipedia.org/wiki/Injective_function
>
>> ...
>>>I wonder what was the motivation to require preallocated data set
>>>names rather than the more flexible alternative of DDNAMEs?
>>
>>I believe it’s using ICONV on the USS side under the covers, which takes a 
>>data set name.
>> 
>Appendix K of the Command Ref. does not list iconv as among the
>utilities that accept data set names.  Of course, IBM is allowed to use
>non-GUPI interfaces internally.
>
>-- 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: UTF16 to EBCDIC

[Mike Schwab]

EBCDIC, EBCDIC DBCS, UTF-16, and ASCII all require the user to know
the code page for the data set.  UTF-8 uses up to 32 bits and
incorporates all languages include several DBCS languages from Asia.

On Sun, Feb 9, 2020 at 10:07 PM Edward Finnell
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>
> Guess I don't see the reasoning. IBM has had DBCS for decades.
>
> http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In a message 
> dated 2/9/2020 9:58:05 PM Central Standard Time, li...@akphs.com writes:
> Gil corrected me:
> > You're describing UTF-8.  UTF-16 uses 16-bit code units.>
> >  https://en.wikipedia.org/wiki/UTF-16
>
>
> Jeez, yes, of course. Brainfart! Thanks.
>
> --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



-- 
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

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Mon, 10 Feb 2020 04:06:35 +, Edward Finnell < wrote:

>Guess I don't see the reasoning. IBM has had DBCS for decades.
>
>http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In
ITYM:
 http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1

UTF-8 has enormous compatibility with ASCII.  IBM DBCS has such
compatibility neither with EBCDIC nor with ASCII.  On Linux or MacOS
I can code C source programs or shell scripts alike in ASCII or UTF-8.
Can COBOL or HLASM source, or JCL be DBCS?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Mon, 10 Feb 2020 04:06:35 +, Edward Finnell < wrote:

>Guess I don't see the reasoning. IBM has had DBCS for decades.
>
>http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In
ITYM:
 http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1


>> You're describing UTF-8.  UTF-16 uses 16-bit code units.>    
>>  https://en.wikipedia.org/wiki/UTF-16
>
>
>Jeez, yes, of course. Brainfart! Thanks.
>
>--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: UTF16 to EBCDIC

[Steve Smith]

*ALL* talk about Unicode is dangerous ;-).  Your description is of UTF-8,
which can use 1, 2, 3, or 4 bytes per character, while UTF-16 uses only
either 2 or 4.  Both are variable-length encoding, although the variability
of UTF-16 is... strange.

sas


On Sun, Feb 9, 2020 at 9:51 PM Phil Smith III  wrote:

> Mike Schwab wrote:
>
> >Would UTF-16 to UTF-8 be a better conversion?  You still have to be
>
> >certain of the source character set.  And is supported by some z/OS
>
> >software.
>
>
>
> As Cameron indicated, your comment doesn't quite make sense. UTF-16 is
> just a variable-length encoding, in which basic ASCII*
> (0-127) are single-byte, some characters are two-byte, some three-, and
> some four-. More efficient, especially in the "mostly basic
> ASCII" case.
>
>
>
> *Yes, I know, talking about "ASCII" in the context of Unicode is dangerous
> and arguably incorrect. You know what I mean.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Edward Finnell]

Guess I don't see the reasoning. IBM has had DBCS for decades.

http://www-01.ibm.com/support/docview.wss?uid=swg27004197=1In a message 
dated 2/9/2020 9:58:05 PM Central Standard Time, li...@akphs.com writes:
Gil corrected me:
> You're describing UTF-8.  UTF-16 uses 16-bit code units.>    
>  https://en.wikipedia.org/wiki/UTF-16


Jeez, yes, of course. Brainfart! Thanks.

--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: UTF16 to EBCDIC

[Phil Smith III]

Gil corrected me:

> You're describing UTF-8.  UTF-16 uses 16-bit code units.
>  
> https://en.wikipedia.org/wiki/UTF-16

 

Jeez, yes, of course. Brainfart! Thanks.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Sun, 9 Feb 2020 21:50:57 -0500, Phil Smith III wrote:

>Mike Schwab wrote:
>
>>Would UTF-16 to UTF-8 be a better conversion?  You still have to be
>>certain of the source character set.  And is supported by some z/OS
>>software.
>
I believe HLASM on Linux would probably mistake UTF-8 (IBM 1208)
SYSIN for ISO8859-1 and translate it SBCS-wise to IBM-037.  It might
even work if ISO code points 128-255 appear only in quoted strings.
E.g.   DC C'матрёшка'

COBOL?

>As Cameron indicated, your comment doesn't quite make sense. UTF-16 is just a 
>variable-length encoding, in which basic ASCII*
>(0-127) are single-byte, some characters are two-byte, some three-, and some 
>four-. More efficient, especially in the "mostly basic
>ASCII" case.
> 
You're describing UTF-8.  UTF-16 uses 16-bit code units.
https://en.wikipedia.org/wiki/UTF-16

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Phil Smith III]

Mike Schwab wrote:

>Would UTF-16 to UTF-8 be a better conversion?  You still have to be

>certain of the source character set.  And is supported by some z/OS

>software.

 

As Cameron indicated, your comment doesn't quite make sense. UTF-16 is just a 
variable-length encoding, in which basic ASCII*
(0-127) are single-byte, some characters are two-byte, some three-, and some 
four-. More efficient, especially in the "mostly basic
ASCII" case.

 

*Yes, I know, talking about "ASCII" in the context of Unicode is dangerous and 
arguably incorrect. You know what I mean.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Cameron Conacher]

Not sure what you are asking here.
The mainframe supports UTF-16BE Basic Mapping Plane 0 natively as National
Characters in COBOL - PIC N.

UTF-16 to UTF-8 would not lose any characters during transformation since
they both encode Unicode.


On Sun, Feb 9, 2020 at 6:21 PM Mike Schwab  wrote:

> Would UTF-16 to UTF-8 be a better conversion?  You still have to be
> certain of the source character set.  And is supported by some z/OS
> software.
>
> On Sun, Feb 9, 2020 at 11:55 AM Cameron Conacher 
> wrote:
> >
> > Ah yes,
> > I mis-typed/fat fingered the reply.
> > As you say, it SHOULD read EDCICONV.
> >
> > And, yes Unicode allows for over a million possible character
> combination.
> > National Language support in the mainframe allows for the characters in
> > basic mapping plane 0, so only about 65,000 character combinations.
> > And IBM-037 only has 256 combinations.
> > So, be aware of character loss as you transform from one to the other.
> >
> > On Sat, Feb 8, 2020 at 11:45 AM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > On Sat, 8 Feb 2020 09:09:58 -0600, Paul Gilmartin wrote:
> > >
> > > >On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:
> > > >
> > > >>I use ICONV.
> > > >>
> > > >>//MYSTEP EXEC PROC=EDICONV,
> > > >>//INFILE='MY.input.file.name(member)',
> > > >>//OUTFILE='My.Output.FileName',
> > > >>//FROMC='1208',
> > > >>//TOC='IBM-037'
> > > >>
> > > >>
> > > >>The PROC is licensed IBM material. It executes program EDICCONV
> > > >>
> > > >Is the documentation available only with purchase?
> > > >
> > > Ah!  Do you mean perhaps, JCL procedure EDCICONV?
> > >
> > >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/iconvubatch.htm
> > >
> > > I wonder what was the motivation to require preallocated data set
> > > names rather than the more flexible alternative of DDNAMEs?
> > >
> > > >How does it handle characters absent from IBM-037?
> > > >
> > > >1208 is UTF-8, not UTF-16.  I assume the example is schematic.
> > >
> > > -- 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
>
>
>
> --
> 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: UTF16 to EBCDIC

[Mike Schwab]

Would UTF-16 to UTF-8 be a better conversion?  You still have to be
certain of the source character set.  And is supported by some z/OS
software.

On Sun, Feb 9, 2020 at 11:55 AM Cameron Conacher  wrote:
>
> Ah yes,
> I mis-typed/fat fingered the reply.
> As you say, it SHOULD read EDCICONV.
>
> And, yes Unicode allows for over a million possible character combination.
> National Language support in the mainframe allows for the characters in
> basic mapping plane 0, so only about 65,000 character combinations.
> And IBM-037 only has 256 combinations.
> So, be aware of character loss as you transform from one to the other.
>
> On Sat, Feb 8, 2020 at 11:45 AM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Sat, 8 Feb 2020 09:09:58 -0600, Paul Gilmartin wrote:
> >
> > >On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:
> > >
> > >>I use ICONV.
> > >>
> > >>//MYSTEP EXEC PROC=EDICONV,
> > >>//INFILE='MY.input.file.name(member)',
> > >>//OUTFILE='My.Output.FileName',
> > >>//FROMC='1208',
> > >>//TOC='IBM-037'
> > >>
> > >>
> > >>The PROC is licensed IBM material. It executes program EDICCONV
> > >>
> > >Is the documentation available only with purchase?
> > >
> > Ah!  Do you mean perhaps, JCL procedure EDCICONV?
> >
> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/iconvubatch.htm
> >
> > I wonder what was the motivation to require preallocated data set
> > names rather than the more flexible alternative of DDNAMEs?
> >
> > >How does it handle characters absent from IBM-037?
> > >
> > >1208 is UTF-8, not UTF-16.  I assume the example is schematic.
> >
> > -- 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



-- 
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

Re: UTF16 to EBCDIC

[Phil Smith III]

Gil wrote:

>But no indication that it throws an error.  Of course the iconv utility could 
>check
>the output of iconv() and report its own error.

 

Hmm. I thought I'd seen it throw an error but maybe not, and system is down ATM 
so I can't check

 

In any case, one approach might be to go UTF==>EBCDIC==>UTF and make sure it 
round-trips successfully, which it won't if it's lossy.

 

On my list of "things to do when I finish the time machine": No ASCII/EBCDIC 
divide; no null-terminated strings. And something else, I forget what right 
now. I have time, I can always do it last week.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Cameron Conacher]

Ah yes,
I mis-typed/fat fingered the reply.
As you say, it SHOULD read EDCICONV.

And, yes Unicode allows for over a million possible character combination.
National Language support in the mainframe allows for the characters in
basic mapping plane 0, so only about 65,000 character combinations.
And IBM-037 only has 256 combinations.
So, be aware of character loss as you transform from one to the other.

On Sat, Feb 8, 2020 at 11:45 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 8 Feb 2020 09:09:58 -0600, Paul Gilmartin wrote:
>
> >On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:
> >
> >>I use ICONV.
> >>
> >>//MYSTEP EXEC PROC=EDICONV,
> >>//INFILE='MY.input.file.name(member)',
> >>//OUTFILE='My.Output.FileName',
> >>//FROMC='1208',
> >>//TOC='IBM-037'
> >>
> >>
> >>The PROC is licensed IBM material. It executes program EDICCONV
> >>
> >Is the documentation available only with purchase?
> >
> Ah!  Do you mean perhaps, JCL procedure EDCICONV?
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/iconvubatch.htm
>
> I wonder what was the motivation to require preallocated data set
> names rather than the more flexible alternative of DDNAMEs?
>
> >How does it handle characters absent from IBM-037?
> >
> >1208 is UTF-8, not UTF-16.  I assume the example is schematic.
>
> -- 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: UTF16 to EBCDIC

[Paul Gilmartin]

On Sat, 8 Feb 2020 16:31:56 -0500, Phil Smith III wrote:
>
>>How does it handle characters absent from IBM-037?
>
>I expect it will throw an error. This is, as you (Gil) know, one of the 
>problems with OP’s query: you can’t stuff thousands of pounds of potatoes into 
>a 256-pound sack. (OK, characters, not potatoes.)  ...
>
The Command Ref. says:
If the input contains a character that is not valid in the destination code 
set, behavior
depends on the system's iconv() function. See z/OS XL C/C++ Runtime Library 
Reference
for more information about the character that is used for converting 
incorrect characters.
Which says:
If iconv() encounters a character in the input buffer that is valid, but 
for which
a conversion is not defined in the conversion descriptor, cd, then iconv() 
performs
a nonidentical conversion on this character. The conversion is 
implementation-defined.

But no indication that it throws an error.  Of course the iconv utility could 
check
the output of iconv() and report its own error.

"implementation-defined"?  This is the document that's supposed to provide that
definition.  I'll submit an RCF.  And a minor one.  "nonidentical" is invented 
nonsense.
the correct term is "injective:"  
https://en.wikipedia.org/wiki/Injective_function

> ...
>>I wonder what was the motivation to require preallocated data set
>>names rather than the more flexible alternative of DDNAMEs?
>
>I believe it’s using ICONV on the USS side under the covers, which takes a 
>data set name.
> 
Appendix K of the Command Ref. does not list iconv as among the
utilities that accept data set names.  Of course, IBM is allowed to use
non-GUPI interfaces internally.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Phil Smith III]

Gil wrote:

>How does it handle characters absent from IBM-037?

 

I expect it will throw an error. This is, as you (Gil) know, one of the 
problems with OP’s query: you can’t stuff thousands of pounds of potatoes into 
a 256-pound sack. (OK, characters, not potatoes.) For those who don’t 
understand, consider these two characters:

зέ

The first one is Cyrillic, the second Greek. In EBCDIC (assuming the most 
common code pages of 1025 for Cyrillic and 825 for Greek), both are x’B2’. So 
while you can have a Unicode string encoded with any of the UTF family that 
contains both characters, you can’t have “an EBCDIC string” that does so 
without some metadata that says “Byte 1 is 1025 and byte 2 is 825”, which is 
(fairly) unlikely.

 

Thus you can take з and tell ICONV or equivalent to convert FROM 1025 TO 
UTF-whatever, or take έ and tell ICONV or equivalent to convert FROM 825 TO 
UTF-whatever. You’ll get two different UTF-encoded values for two different 
U+ values, as you’d expect. And you can convert back, as long as your input 
string fits entirely within the target 256-byte EBCDIC code page.

 

This stuff gets pretty complex, with terms like “code point”, “Character”, 
“glyph”, and “grapheme” used somewhat interchangeably (but all are subtly 
different in specific contexts). So tread carefully.

 

>I wonder what was the motivation to require preallocated data set

>names rather than the more flexible alternative of DDNAMEs?

 

I believe it’s using ICONV on the USS side under the covers, which takes a data 
set name.

 

…phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Sat, 8 Feb 2020 09:09:58 -0600, Paul Gilmartin wrote:

>On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:
>
>>I use ICONV.
>>
>>//MYSTEP EXEC PROC=EDICONV,
>>//INFILE='MY.input.file.name(member)',
>>//OUTFILE='My.Output.FileName',
>>//FROMC='1208',
>>//TOC='IBM-037'
>>
>>
>>The PROC is licensed IBM material. It executes program EDICCONV
>> 
>Is the documentation available only with purchase?
> 
Ah!  Do you mean perhaps, JCL procedure EDCICONV?

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcux01/iconvubatch.htm

I wonder what was the motivation to require preallocated data set
names rather than the more flexible alternative of DDNAMEs?

>How does it handle characters absent from IBM-037?
>
>1208 is UTF-8, not UTF-16.  I assume the example is schematic.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Paul Gilmartin]

On Sat, 8 Feb 2020 09:37:29 -0500, Cameron Conacher wrote:

>I use ICONV.
>
>//MYSTEP EXEC PROC=EDICONV,
>//INFILE='MY.input.file.name(member)',
>//OUTFILE='My.Output.FileName',
>//FROMC='1208',
>//TOC='IBM-037'
>
>
>The PROC is licensed IBM material. It executes program EDICCONV
> 
Is the documentation available only with purchase?

How does it handle characters absent from IBM-037?

1208 is UTF-8, not UTF-16.  I assume the example is schematic.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Cameron Conacher]

I use ICONV.

//MYSTEP EXEC PROC=EDICONV,
//INFILE='MY.input.file.name(member)',
//OUTFILE='My.Output.FileName',
//FROMC='1208',
//TOC='IBM-037'


The PROC is licensed IBM material. It executes program EDICCONV

On Thu, Feb 6, 2020 at 9:29 PM Jake Anderson 
wrote:

> Hi
>
> Cross posted
>
> I am looking way to translate from UTF16 to EBCDIC. When I do D UNI,ALL i
> do not see UTF16 to EBCDIC conversion table.
>
> Is it something I need to load as CUNIMG or I have to create a table then
> refer them while FTP ing ?
>
> Please advise
>
> Jake
>
> --
> 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: UTF16 to EBCDIC

[Paul Gilmartin]

On Fri, 7 Feb 2020 19:17:30 +, Seymour J Metz wrote:

>Have you read https colon 
>//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
> What are your source and target CCIDs?
>
I had difficulty repairing your desperate attempt to circumvent a roboprig.  
Perhaps:

https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf

>Note that EBCDIC is a family of code points and UTF16 is a Unicode transform; 
  ^^
ITYM "code pages" or "CCSIDs".

> ... neither identifies a single character set. In particular, IBM supports 
> both the current Unicode and some older versions.

Well said.


From: Jake Anderson
Sent: Thursday, February 6, 2020 9:29 PM

I am looking way to translate from UTF16 to EBCDIC. When I do D UNI,ALL i
do not see UTF16 to EBCDIC conversion table.

Is it something I need to load as CUNIMG or I have to create a table then
refer them while FTP ing ?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF16 to EBCDIC

[Seymour J Metz]

Have you read https colon 
//www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa380680/$file/cunu100_v2r4.pdf?
 What are your source and target CCIDs?

Note that EBCDIC is a family of code points and UTF16 is a Unicode transform; 
neither identifies a single character set. In particular, IBM supports both the 
current Unicode and some older versions.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Jake Anderson 
Sent: Thursday, February 6, 2020 9:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: UTF16 to EBCDIC

Hi

Cross posted

I am looking way to translate from UTF16 to EBCDIC. When I do D UNI,ALL i
do not see UTF16 to EBCDIC conversion table.

Is it something I need to load as CUNIMG or I have to create a table then
refer them while FTP ing ?

Please advise

Jake

--
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: UTF16 to EBCDIC

[Paul Gilmartin]

On Fri, 7 Feb 2020 06:29:26 +0400, Jake Anderson wrote:
>
>I am looking way to translate from UTF16 to EBCDIC. When I do D UNI,ALL i
>do not see UTF16 to EBCDIC conversion table.
> 
Which EBCDIC?  1047? 500? 037? other (specify)?
How do you want to handle UTF16 characters that do not exist
in your chosen EBCDIC code page?

>Is it something I need to load as CUNIMG or I have to create a table then
>refer them while FTP ing ?
>
See: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cunu100/uniccsi.htm
for IBM UTF-16 CCSIDs.

>Please advise
> 
You asked a question on IBMTCP-L, similar, but specific to FTP, where I
suggested MBDATACONN, as in:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/mbcschina.htm
Also:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.halz001/ftpcasmbdataconn.htm

Is that example useful?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN