Re: Cobol EBCDIC to ASCII
"ASCII" is a term of art defined by ANSI, just as 8859-1 is a term of art
defined by ISO. EBCDIC is a term of art defined by IBM, and IBM has always had
multiple code page for it.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Alan Altmark
Sent: Monday, February 26, 2018 3:45 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol EBCDIC to ASCII
On Tue, 20 Feb 2018 14:35:57 +, Seymour J Metz wrote:
>The problem is not that the term "ASCII" is ambiguous; it isn't. The problem
>is that people don't understand what ASCII is and
> refer to things that aren't ASCII as "ASCII". Code pages like 437, 850 and
> ISO-8859-x aren't ASCII, and if IBM documentation
> refers to them as ACII then that is a disservice to your customers.
>
>There are, however, issues as to how ASCII should be converted to other code
>pages. For example, ASCII defines a broken
> vertical bar, nut it is common to display | as a solid vertical bar. Many
> code pages have both characters, and either choice
> can lead to problems.
At a point in history, "ASCII" and "EBCDIC" meant only one thing, but they have
since evolved. They retained, however, their core DNA. It is to that DNA we
refer when we say their names without qualification. The term "US-ASCII"
refers to the original 7-bit specification adopted by ANSI as X3.4. It is
preserved in IBM code page 367.
The nice thing about ASCII is that all descendants of US-ASCII simply added
characters 128 to 255. The first 128 code points remained untouched. How a
platform displayed the 32 control characters in a non-control context, or the
appearance of undefined code point 0x7f (i.e. in a character generator), was
beyond the scope of the ANSI standard.
EBCDIC, on the other hand, suffered under the strain of trying to maintain
compatibility with its BCD ancestor, the needs of the different programming
languages, a recalcitrant ANSI standards committee, and the limitations of the
hardware at the time ("Thank you, Mr. Hollerith!").
There was apparently an objective that EBCDIC have all the graphics of ASCII
and none that ASCII did not. "Men plan, gods laugh." There were too many
participants at the table and compromises were made that we deal with today.
The equivalence eventually made it into the literature as IBM code page 38.
Right. I don't use it, either.
The book "Coded Character Sets, History and Development" by Charles Mackenzie,
IBM (Addison-Wesley, System Programming Series, 1980) is as fascinating as it
is horrifyingly geeky.
Alan Altmark
IBM
--
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: Cobol EBCDIC to ASCII
On Tue, 20 Feb 2018 14:35:57 +, Seymour J Metz wrote:
>The problem is not that the term "ASCII" is ambiguous; it isn't. The problem
>is that people don't understand what ASCII is and
> refer to things that aren't ASCII as "ASCII". Code pages like 437, 850 and
> ISO-8859-x aren't ASCII, and if IBM documentation
> refers to them as ACII then that is a disservice to your customers.
>
>There are, however, issues as to how ASCII should be converted to other code
>pages. For example, ASCII defines a broken
> vertical bar, nut it is common to display | as a solid vertical bar. Many
> code pages have both characters, and either choice
> can lead to problems.
At a point in history, "ASCII" and "EBCDIC" meant only one thing, but they have
since evolved. They retained, however, their core DNA. It is to that DNA we
refer when we say their names without qualification. The term "US-ASCII"
refers to the original 7-bit specification adopted by ANSI as X3.4. It is
preserved in IBM code page 367.
The nice thing about ASCII is that all descendants of US-ASCII simply added
characters 128 to 255. The first 128 code points remained untouched. How a
platform displayed the 32 control characters in a non-control context, or the
appearance of undefined code point 0x7f (i.e. in a character generator), was
beyond the scope of the ANSI standard.
EBCDIC, on the other hand, suffered under the strain of trying to maintain
compatibility with its BCD ancestor, the needs of the different programming
languages, a recalcitrant ANSI standards committee, and the limitations of the
hardware at the time ("Thank you, Mr. Hollerith!").
There was apparently an objective that EBCDIC have all the graphics of ASCII
and none that ASCII did not. "Men plan, gods laugh." There were too many
participants at the table and compromises were made that we deal with today.
The equivalence eventually made it into the literature as IBM code page 38.
Right. I don't use it, either.
The book "Coded Character Sets, History and Development" by Charles Mackenzie,
IBM (Addison-Wesley, System Programming Series, 1980) is as fascinating as it
is horrifyingly geeky.
Alan Altmark
IBM
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 14:13:27 -0600, Paul Gilmartin wrote: >How about USASCII? Is that unambiguously the 7-bit set? > >I've encountered two EBCDIC C implementations. One of them returned "true" if >the EBCDIC character translated to ASCII was a USASCII character. The other >returned :true" simply if the EBCDIC code point was less than 128. Yes, USASCII (US-ASCII) is the original 7-bit code set. >That's *so* 20th century! And 95 is better than 56. And luck had little to >do with it; >it was more lackadaisical design. 7-bit ASCII was extant when EBCDIC was >conceived. >Prudence should have dictated that EBCDIC code points correspinding to those 95 >glyphs be kept invariant. Perhaps, but IBM was trying to provide a proof point for the "International" part of its name. I speculate that it was about reusing the existing character generator implementations in the field and that those were exceedingly stingy in terms of how many glyphs they would display. While that explains things like National Use Characters, it's doesn't explain why code page designers would allow characters with existing assignments to just float around. (dope slap) All influenced by APL, ATMS, Selectrics, print chains, and an apparent lack of coordination. And WHY would you move lower case 'a' to 0x61 when the code point assignments are arbitrary in the post-card reader era to begin with? (baseball bat). "Why, Santy Clause, WHY?" Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
No; the customer might be using different code pages for different things. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Monday, February 19, 2018 9:08 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol EBCDIC to ASCII Phil/Gil: Correct, sorry been a week, CP285 is a UK EBCDIC codepage. But my question still stands ... 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a STC in Cobol 2. The STC decrypts and then converts to EBCDIC... My issue is CAN i query a codepage or CCSID on z/OS to find out what the customer is using without a parameter of some sort. Regards, On Sun, Feb 18, 2018 at 8:34 PM, Mike Schwab wrote: > Knowing what country the data is coming from would greatly reduce the > possibilities to one or a handful of code pages. > > On Sun, Feb 18, 2018 at 3:40 PM, Phil Smith III wrote: > > scott Ford wrote, in part: > > > >>The ASCII is CP 285 UK ..but we have to support all .I am making sure I > > > > > > > > That's not ASCII. This is the point others have been making: you can't > > really say "ASCII" unless you mean x'00' through x'127' *and nothing > else*: > > all you can say is "It's not EBCDIC". Once you start talking other "code > > pages", you either need to know which it is, or you have to make an > > assumption. Period. > > > > > > > > And from my reading, code page 285 is an EBCDIC code page. > > > > > > > > Sorry to sound like a hardass about this, but I'm not sure your question > has > > a meaningful answer, based on what you've said so far. > > > > > > > > .phsiii > > > > > > -- > > 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 > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” http://secure-web.cisco.com/1Nl-kqivIetKnGz07tNadT5TzVFbPcjcXv8C0TiXSYn1nG8MRacOUJirmfnBXL6KedZCSPQZ_Y0ClLsq3tDUMJHhz41b150bdiFHhkEuZEShzgmjWWhymGpmtX0pA9yA0yISQDjNdljorXEa8PvJhknUOwaNpaZqUDi9yyvlCYK3qlwDzwNCrzp9Ce4e3sO67M4ZLk671ut2roC0LkzAD_dBAKwP0Ir8ouD-PEAhmBoKxRTHuOdepMEX1CtsSHvjAujQeX2g4IcC0uV-eETvd6q2MI-tzYRkt793Y-LpFnaemaBHZ0QWS1hLFr91rbUB4cJUYMhK9DpQqT68Z_uERH2TdsvLoBJJEtmWBS3OCi8Ja0taAAIw1UdTyeq95DLy5gVvK_EL7vwc5k-QH2Qcz0TkSEKR4fijQHommKHGzmhCgLdD1AA7i7FiNoAlAKlYG/http%3A%2F%2Fwww.idmworks.com scott.f...@idmworks.com Blog: http://secure-web.cisco.com/1hOlns0CEmEAp1ej5h7E1nIUAta--4AyNNh_bJ7CR_tfEDjYOfdXayWRHfT7cCE4mOhs4atPIAjuDhpKSp133tZku8ZC0dE5aLOuQu3WZm0_QtUTjwNGl2wuHdSnHRc2TbVHCniqbQE3sQVdhogaXf9rYc4MqforWFcqDjNkBDxB9E2DaTcslEzZ7VmCmseFstddcHEeeCcFZt1OFefvPsk3XDRhPp6uGshpJA03pC_zsizaTudrQM9e6k4Orb62ySj8sBjG8zKHVy9A3QBS98pUaqaUTM3rQCVDKhaWwvpv7YeAYSWl4n8quEumhIkXX17TcMZwIrpnIcXLOL1uSnINYmRMnKaj5KdLxfmSQrw34X3jP5N5Hc7Y7Scbf8IsyQS_NTRDkJkDFEgS7y3I42BQJyuDMv8Bd72jsfIJtFWeHgEdcQ-nYz9ZDXFRX5wuC/http%3A%2F%2Fwww.idmworks.com%2Fblog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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: Cobol EBCDIC to ASCII
The problem is not that the term "ASCII" is ambiguous; it isn't. The problem is
that people don't understand what ASCII is and refer to things that aren't
ASCII as "ASCII". Code pages like 437, 850 and ISO-8859-x aren't ASCII, and if
IBM documentation refers to them as ACII then that is a disservice to your
customers.
There are, however, issues as to how ASCII should be converted to other code
pages. For example, ASCII defines a broken vertical bar, nut it is common to
display | as a solid vertical bar. Many code pages have both characters, and
either choice can lead to problems.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Alan Altmark
Sent: Monday, February 19, 2018 1:12 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol EBCDIC to ASCII
On Sun, 18 Feb 2018 13:59:37 -0600, Paul Gilmartin wrote:
>I believe "ASCII" can properly be used to refer to the first 128 characters in
>CCSID 819.
>including special characters. Informally, many use "ASCII" to refer to CCSID
>819 or
>other ISO-LATIN code pages.
I've been doing code page and translation table development and analysis since
about 1987. The term "ASCII" is just as ambiguous as "EBCDIC", as without
qualification each term only sets an expectation for the 8-bit encoding of a
somewhat vague set of glyphs.
The original 7-bit ASCII established a full 95-glyph character set that remains
invariant today among all 8-bit ASCII code pages. EBCDIC wasn't quite so
lucky, as it has only 56 invariant characters. It would be 82, but lower case
a-z can vary or be non-existent. If your data is composed of only the 56
common invariant characters, any EBCDIC and ASCII code page will suffice. All
"Latin" EBCDIC code pages will work for lower case a-z.
Here are the common invariant characters.
A-Z
0-9
space
. , + - / * ( ) < > = % : ; _ ? ' " &
If you also have:
@ ! ~ # $ ^ | [ ] { } `
then any ASCII code page will do, but you need to select your EBCDIC code page
carefully.
If you have any other glyph, then both ASCII and EBCDIC code pages must be
selected with care.
Alan Altmark
IBM Lab Services
--
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: Cobol EBCDIC to ASCII
If it is coming from a company, they would most likely be in the primary language of the country (or region). If it is coming from an individual, then it could be anything in any country. Could you convince your clients to use UTF-8? On Mon, Feb 19, 2018 at 4:06 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 19 Feb 2018 15:41:11 -0600, Mike Schwab wrote: > >>Can you find out the IP address the file is coming from? If so, then >>you could look up the country by looking in the assigned range table. >>https://www.codeproject.com/Articles/28363/How-to-convert-IP-address-to-country-name >> > Seriously? How many code pages are in use in the USA? And then > there's VPN. And multinational organizations. > > -- gil > > -- > 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: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 15:41:11 -0600, Mike Schwab wrote: >Can you find out the IP address the file is coming from? If so, then >you could look up the country by looking in the assigned range table. >https://www.codeproject.com/Articles/28363/How-to-convert-IP-address-to-country-name > Seriously? How many code pages are in use in the USA? And then there's VPN. And multinational organizations. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Can you find out the IP address the file is coming from? If so, then you could look up the country by looking in the assigned range table. https://www.codeproject.com/Articles/28363/How-to-convert-IP-address-to-country-name On Mon, Feb 19, 2018 at 8:08 AM, scott Ford wrote: > Phil/Gil: > > Correct, sorry been a week, CP285 is a UK EBCDIC codepage. > But my question still stands ... > > 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a > STC in Cobol > 2. The STC decrypts and then converts to EBCDIC... > > My issue is CAN i query a codepage or CCSID on z/OS to find out what the > customer is using without a parameter of some sort. > > Regards, > > On Sun, Feb 18, 2018 at 8:34 PM, Mike Schwab > wrote: > >> Knowing what country the data is coming from would greatly reduce the >> possibilities to one or a handful of code pages. >> >> On Sun, Feb 18, 2018 at 3:40 PM, Phil Smith III wrote: >> > scott Ford wrote, in part: >> > >> >>The ASCII is CP 285 UK ..but we have to support all .I am making sure I >> > >> > >> > >> > That's not ASCII. This is the point others have been making: you can't >> > really say "ASCII" unless you mean x'00' through x'127' *and nothing >> else*: >> > all you can say is "It's not EBCDIC". Once you start talking other "code >> > pages", you either need to know which it is, or you have to make an >> > assumption. Period. >> > >> > >> > >> > And from my reading, code page 285 is an EBCDIC code page. >> > >> > >> > >> > Sorry to sound like a hardass about this, but I'm not sure your question >> has >> > a meaningful answer, based on what you've said so far. >> > >> > >> > >> > .phsiii >> > >> > >> > -- >> > 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 >> > > > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > 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: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 12:12:07 -0600, Alan Altmark wrote: > >I've been doing code page and translation table development and analysis since >about 1987. The term "ASCII" is just as ambiguous as "EBCDIC", as without >qualification each term only sets an expectation for the 8-bit encoding of a >somewhat vague set of glyphs. > How about USASCII? Is that unambiguously the 7-bit set? I've encountered two EBCDIC C implementations. One of them returned "true" if the EBCDIC character translated to ASCII was a USASCII character. The other returned :true" simply if the EBCDIC code point was less than 128. >The original 7-bit ASCII established a full 95-glyph character set that >remains invariant today among all 8-bit ASCII code pages. EBCDIC wasn't >quite so lucky, as it has only 56 invariant characters. It would be 82, but >lower case a-z can vary or be non-existent. If your data is composed of only >the 56 common invariant characters, any EBCDIC and ASCII code page will >suffice. All "Latin" EBCDIC code pages will work for lower case a-z. > That's *so* 20th century! And 95 is better than 56. And luck had little to do with it; it was more lackadaisical design. 7-bit ASCII was extant when EBCDIC was conceived. Prudence should have dictated that EBCDIC code points correspinding to those 95 glyphs be kept invariant. If the domain of practically any problem is sufficiently restricted the solution becomes trivial. And mostly useless. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, 19 Feb 2018 18:17:17 +, Frank Swarbrick wrote: >For whatever its worth, once you determine what "ASCII" code page the source >is in and what EBCDIC code page you want the result in you can use Enterprise >COBOL native intrinsic functions to perform the conversion. Let's assume(!) >that the source code page is just the basic Latin-1/ISO-8859-1 (IBM CCSID 819) >and the EBCDIC code page is U.K. Latin-1 (CCSID 285)... > >MOVE FUNCTION DISPLAY-OF ( FUNCTION NATIONAL-OF (ASCII-IN, 819) , 285 ) TO >EBCDIC-OUT > >The "inner function" converts from ASCII CCSID 819 to UTF-16, and the outer >function converts from UTF-16 to EBCDIC CCSID 285. > >This doesn't, of course, answer the question of what the source code page is. >They either need to tell you or it needs to be provided as part of the >protocol. > Nor does it answer the question of how to handle the error that should be reported on encountering a CCSID 819 character not present in 285. If the user is in UK, it's likely to be ISO-8859-15 (CCSID 923) rather than 819. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
For whatever its worth, once you determine what "ASCII" code page the source is in and what EBCDIC code page you want the result in you can use Enterprise COBOL native intrinsic functions to perform the conversion. Let's assume(!) that the source code page is just the basic Latin-1/ISO-8859-1 (IBM CCSID 819) and the EBCDIC code page is U.K. Latin-1 (CCSID 285)... MOVE FUNCTION DISPLAY-OF ( FUNCTION NATIONAL-OF (ASCII-IN, 819) , 285 ) TO EBCDIC-OUT The "inner function" converts from ASCII CCSID 819 to UTF-16, and the outer function converts from UTF-16 to EBCDIC CCSID 285. This doesn't, of course, answer the question of what the source code page is. They either need to tell you or it needs to be provided as part of the protocol. Frank From: IBM Mainframe Discussion List on behalf of Wendell Lovewell Sent: Monday, February 19, 2018 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cobol EBCDIC to ASCII Hi Scot. It appears that EZACIE2A and EZACIA2E are aliases for EZACICTR.A, which is described in http://www-01.ibm.com/support/docview.wss?uid=swg21256665 This isn't really a COBOL answer, but it seems to me you could replace the table names in EZACICTR from "US", "CANADIAN", "DUTCH"... to the codepage names supplied in the comments: TRFIRST DS0A DCCL8'AUSGER',A(AUSGER) Austrian/German CECP 273 DCCL8'BELGIAN',A(BELGIAN) Belgian (New) CECP 500 DCCL8'CANADIAN',A(CANADIAN) Canadian Bilingual CECP 037 ... DCCL8'TELNETSE',A(TELNETSE) DCCL8'UK',A(UK) English (UK) CECP 285 DCCL8'US',A(US) English (US) CECP 037 TRENDEQU * This doesn't help identify the codepage, but when you have it, it would allow you to pass the codepage number instead of the table name. It also appears that EZACICTR allows you to pass a complete table instead of the table name, if that would somehow be easier: * *** * * MULTIPLE mode calls * *** * MOVE 'US' to TABLE-NAME. * CALL 'EZACIE2A' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * CALL 'EZACIA2E' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * * *** * * Optional call valid for either mode * *** * CALL 'EZACICTR' USING OUT-BUFFER LENGTH TRANSLATE-TABLE * RETURNING RET-CODE. hth, Wendell Lovewell -- 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: Cobol EBCDIC to ASCII
On Sun, 18 Feb 2018 13:59:37 -0600, Paul Gilmartin wrote:
>I believe "ASCII" can properly be used to refer to the first 128 characters in
>CCSID 819.
>including special characters. Informally, many use "ASCII" to refer to CCSID
>819 or
>other ISO-LATIN code pages.
I've been doing code page and translation table development and analysis since
about 1987. The term "ASCII" is just as ambiguous as "EBCDIC", as without
qualification each term only sets an expectation for the 8-bit encoding of a
somewhat vague set of glyphs.
The original 7-bit ASCII established a full 95-glyph character set that remains
invariant today among all 8-bit ASCII code pages. EBCDIC wasn't quite so
lucky, as it has only 56 invariant characters. It would be 82, but lower case
a-z can vary or be non-existent. If your data is composed of only the 56
common invariant characters, any EBCDIC and ASCII code page will suffice. All
"Latin" EBCDIC code pages will work for lower case a-z.
Here are the common invariant characters.
A-Z
0-9
space
. , + - / * ( ) < > = % : ; _ ? ' " &
If you also have:
@ ! ~ # $ ^ | [ ] { } `
then any ASCII code page will do, but you need to select your EBCDIC code page
carefully.
If you have any other glyph, then both ASCII and EBCDIC code pages must be
selected with care.
Alan Altmark
IBM Lab Services
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Hi Scot. It appears that EZACIE2A and EZACIA2E are aliases for EZACICTR.A, which is described in http://www-01.ibm.com/support/docview.wss?uid=swg21256665 This isn't really a COBOL answer, but it seems to me you could replace the table names in EZACICTR from "US", "CANADIAN", "DUTCH"... to the codepage names supplied in the comments: TRFIRST DS0A DCCL8'AUSGER',A(AUSGER) Austrian/German CECP 273 DCCL8'BELGIAN',A(BELGIAN) Belgian (New) CECP 500 DCCL8'CANADIAN',A(CANADIAN) Canadian Bilingual CECP 037 ... DCCL8'TELNETSE',A(TELNETSE) DCCL8'UK',A(UK) English (UK) CECP 285 DCCL8'US',A(US) English (US) CECP 037 TRENDEQU * This doesn't help identify the codepage, but when you have it, it would allow you to pass the codepage number instead of the table name. It also appears that EZACICTR allows you to pass a complete table instead of the table name, if that would somehow be easier: * *** * * MULTIPLE mode calls * *** * MOVE 'US' to TABLE-NAME. * CALL 'EZACIE2A' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * CALL 'EZACIA2E' USING OUT-BUFFER LENGTH TABLE-NAME * RETURNING RET-CODE. * * *** * * Optional call valid for either mode * *** * CALL 'EZACICTR' USING OUT-BUFFER LENGTH TRANSLATE-TABLE * RETURNING RET-CODE. hth, Wendell Lovewell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Mon, Feb 19, 2018 at 8:08 AM, scott Ford wrote: > Phil/Gil: > > Correct, sorry been a week, CP285 is a UK EBCDIC codepage. > But my question still stands ... > > 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a > STC in Cobol > 2. The STC decrypts and then converts to EBCDIC... > > My issue is CAN i query a codepage or CCSID on z/OS to find out what the > customer is using without a parameter of some sort. > > Regards, > > In general, no. If you can communicate with the far end, you might be able to ask the software on the user's machine "what is your locale?" and have it reply. But there is nothing in the TCPIP connection that I am aware of which encodes the end user's locale information. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Phil/Gil: Correct, sorry been a week, CP285 is a UK EBCDIC codepage. But my question still stands ... 1. PC/Linux -> sends ascii encrypted data to IBM z/OS , like I mentioned a STC in Cobol 2. The STC decrypts and then converts to EBCDIC... My issue is CAN i query a codepage or CCSID on z/OS to find out what the customer is using without a parameter of some sort. Regards, On Sun, Feb 18, 2018 at 8:34 PM, Mike Schwab wrote: > Knowing what country the data is coming from would greatly reduce the > possibilities to one or a handful of code pages. > > On Sun, Feb 18, 2018 at 3:40 PM, Phil Smith III wrote: > > scott Ford wrote, in part: > > > >>The ASCII is CP 285 UK ..but we have to support all .I am making sure I > > > > > > > > That's not ASCII. This is the point others have been making: you can't > > really say "ASCII" unless you mean x'00' through x'127' *and nothing > else*: > > all you can say is "It's not EBCDIC". Once you start talking other "code > > pages", you either need to know which it is, or you have to make an > > assumption. Period. > > > > > > > > And from my reading, code page 285 is an EBCDIC code page. > > > > > > > > Sorry to sound like a hardass about this, but I'm not sure your question > has > > a meaningful answer, based on what you've said so far. > > > > > > > > .phsiii > > > > > > -- > > 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 > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Knowing what country the data is coming from would greatly reduce the possibilities to one or a handful of code pages. On Sun, Feb 18, 2018 at 3:40 PM, Phil Smith III wrote: > scott Ford wrote, in part: > >>The ASCII is CP 285 UK ..but we have to support all .I am making sure I > > > > That's not ASCII. This is the point others have been making: you can't > really say "ASCII" unless you mean x'00' through x'127' *and nothing else*: > all you can say is "It's not EBCDIC". Once you start talking other "code > pages", you either need to know which it is, or you have to make an > assumption. Period. > > > > And from my reading, code page 285 is an EBCDIC code page. > > > > Sorry to sound like a hardass about this, but I'm not sure your question has > a meaningful answer, based on what you've said so far. > > > > .phsiii > > > -- > 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: Cobol EBCDIC to ASCII
scott Ford wrote, in part: >The ASCII is CP 285 UK ..but we have to support all .I am making sure I That's not ASCII. This is the point others have been making: you can't really say "ASCII" unless you mean x'00' through x'127' *and nothing else*: all you can say is "It's not EBCDIC". Once you start talking other "code pages", you either need to know which it is, or you have to make an assumption. Period. And from my reading, code page 285 is an EBCDIC code page. Sorry to sound like a hardass about this, but I'm not sure your question has a meaningful answer, based on what you've said so far. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
On Sun, 18 Feb 2018 15:49:52 -0500, scott Ford wrote:
>The ASCII is CP 285 UK ...
>
???
According to Linux's iconv, CP285 (CSIBM285 IBM285) appear to be EBCDIC
code pages:
Host: ISO8859-1 output: from_CSIBM285
0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
0 10 20 30 40 50 60 70 80 90 a0 b0 c0 d0 e0 f0
0 0 & - ø Ø ° µ ¢ { } \ 0
1 1 é / É a j ‾ [ A J ÷ 1
2 2 â ê Â Ê b k s ¥ B K S 2
3 3 ä ë Ä Ë c l t · C L T 3
4 4 à è À È d m u © D M U 4
5 5 á í Á Í e n v § E N V 5
6 6 ã î Ã Î f o w ¶ F O W 6
7 7 å ï Å Ï g p x ¼ G P X 7
8 8 ç ì Ç Ì h q y ½ H Q Y 8
9 9 ñ ß Ñ ` i r z ¾ I R Z 9
10 a $ ! ¦ : « ª ¡ ^ ¹ ² ³
11 b . £ , # » º ¿ ] ô û Ô Û
12 c < * % @ ð æ Ð ~ ö ü Ö Ü
13 d ( ) _ ' ý ¸ Ý ¨ ò ù Ò Ù
14 e + ; > = þ Æ Þ ´ ó ú Ó Ú
15 f | ¬ ? " ± ¤ ® × õ ÿ Õ
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Yes, I'm well aware of that. Historically, however, it's been more likely for a started task to use the interface than a batch job. > On Feb 18, 2018, at 16:04, Seymour J Metz wrote: > > Those all apply to batch jobs as well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Those all apply to batch jobs as well. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of J R Sent: Sunday, February 18, 2018 3:25 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol EBCDIC to ASCII Actually, I was primarily thinking of CSCB, CIB, use of QEDIT, etc. On Feb 18, 2018, at 15:00, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: >> Side note 2: I notice that you code in COBOL. If the fact that your >> program runs as an STC is relevant, I would recommend coding in HLASM in >> which control block management is more straightforward. >> > Control blocks for socket or control blocks for iconv? -- 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: Cobol EBCDIC to ASCII
The ASCII is CP 285 UK ..but we have to support all .I am making sure I know my options. I realize about HLASM, i have written it for about 30+ yrs, its not an option , serious lack of experience with another colleague , I could also do C or C++. My thinking is Unicode conversion but the client/server the STC talks to in TCPIP is in Java. My Java experience is about 0 ...i understand a little. I *think* i am looking at CP 285 to 1047..this is working on a Beta we shipped. But i need to be able to handle all the others too... With using EZACIC14 we do a call like this: * **** * MOVE 'US' to TABLE-NAME. * * CALL 'EZACIE2A' USING OUT-BUFFER LENGTH TABLE-NAME* * RETURNING RET-CODE. * * CALL 'EZACIA2E' USING OUT-BUFFER LENGTH TABLE-NAME* * RETURNING RET-CODE. * * * * * * TABLE-NAME Input: Name of the table to be used. We dont pass the codepage, we pass the table - entry name. Of course we tried to explain this to the customer One of collegues asked if we could pass the codepage number and do the translation that way, like this: CODEPAGE=285 I dont know a native Cobol way of doing this without using an Assembler table or program similar to EZACIC14/15. Does anyone else know a native Cobol way ?? On Sun, Feb 18, 2018 at 3:25 PM, J R wrote: > Actually, I was primarily thinking of CSCB, CIB, use of QEDIT, etc. > > On Feb 18, 2018, at 15:00, Paul Gilmartin <000433f07816-dmarc- > requ...@listserv.ua.edu> wrote: > > >> Side note 2: I notice that you code in COBOL. If the fact that your > program runs as an STC is relevant, I would recommend coding in HLASM in > which control block management is more straightforward. > >> > > Control blocks for socket or control blocks for iconv? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Actually, I was primarily thinking of CSCB, CIB, use of QEDIT, etc. On Feb 18, 2018, at 15:00, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: >> Side note 2: I notice that you code in COBOL. If the fact that your >> program runs as an STC is relevant, I would recommend coding in HLASM in >> which control block management is more straightforward. >> > Control blocks for socket or control blocks for iconv? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
Latin 9, ISO 8859-15, is basically Latin-1 with the Euro in place of the currency sign. 923? -- 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 18, 2018 2:59 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol EBCDIC to ASCII On Sun, 18 Feb 2018 19:07:17 +, J R wrote: >If the spec you are working to says nothing about the inbound data other than >"ASCII", you should be able to assume (yes, I know) that the data contains >nothing more than the basic characters 'A' to 'Z', 'a' to 'z' and '0' to '9'. >No punctuation, no characters with diacritical marks, no binary fields, etc. >If this does not describe your data, your spec is incomplete. > I believe "ASCII" can properly be used to refer to the first 128 characters in CCSID 819. including special characters. Informally, many use "ASCII" to refer to CCSID 819 or other ISO-LATIN code pages. If it has euro, it's probably ISO-LATIN (but which?), not ASCII. It might even be the popular UTF-8 (CP 1208), of which the first 128 code points are the same as ASCII. >Other than ASCII, what else do you know about the inbound data? > >Side note 1: I notice you always mention that your program runs as an STC. >This is most likely irrelevant. > >Side note 2: I notice that you code in COBOL. If the fact that your program >runs as an STC is relevant, I would recommend coding in HLASM in which control >block management is more straightforward. > Control blocks for socket or control blocks for iconv? >> On Feb 18, 2018, at212:50, scott Ford wrote: >> >> We read ASCII data via a EZASOKET READ call. The data is encrypted , so we >> decrypt it and then >> convert to EBCDIC. I looked at FTP data and there is a SBDATACON >> parameter..giving both EBCDIC and ASCII ccsids or codepages. >> Just curious: which? Why not transfer in binary, making SBDATACON irrelevant? The less munging the better. >> I dont know what the inbound ASCII data stream codepage is ...after a >> encrypt/Decrypt using AES128 or AES256. >> IOW, do you not know that the source codepage in SBDATACON correctly describes the original data? -- 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: Cobol EBCDIC to ASCII
How sure are you that the inbound data really are ACII? How are fields or records delimited? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Sunday, February 18, 2018 12:49 PM To: IBM-MAIN@listserv.ua.edu Subject: Cobol EBCDIC to ASCII All: I have a question regarding inbound ASCII data. We read ASCII data via a EZASOKET READ call. The data is encrypted , so we decrypt it and then convert to EBCDIC. I looked at FTP data and there is a SBDATACON parameter..giving both EBCDIC and ASCII ccsids or codepages. My problem/issue is: I dont know what the inbound ASCII data stream codepage is ...after a encrypt/Decrypt using AES128 or AES256. I have created a temporary fix to resolve it in our STC usin a CODEPAGE= which is the ASCII codepage. We have been using EZACIC14/15 from the IP Socket Programmer's guide. I am looking for a univeral way to do the conversion, I know I can do NLS and use something like below: CBL DBCS,NSYMBOL(NATIONAL) IDENTIFICATION DIVISION. PROGRAM-ID. MAIN1. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-AREA PICTURE N(50). 01 WS-CCSID PICTURE 9(5). 01 WS-ASCII PICTURE X(50). 01 WS-EBCDIC PICTURE X(50). PROCEDURE DIVISION. MOVE "ABCDE" TO WS-EBCDIC. DISPLAY " WS-EBCDIC = " WS-EBCDIC. MOVE FUNCTION NATIONAL-OF(WS-EBCDIC) TO WS-AREA. DISPLAY " WS-AREA = " WS-AREA. MOVE 819 TO WS-CCSID. MOVE FUNCTION DISPLAY-OF(WS-AREA, WS-CCSID) TO WS-ASCII. DISPLAY " WS-ASCII= " WS-ASCII. DISPLAY "Now let's convert that WS-ASCII back to EBCDIC". MOVE FUNCTION NATIONAL-OF(WS-ASCII,819 ) TO WS-AREA. DISPLAY " WS-AREA = " WS-AREA. MOVE 1140TO WS-CCSID. MOVE FUNCTION DISPLAY-OF(WS-AREA, WS-CCSID) TO WS-EBCDIC. DISPLAY " WS-EBCDIC = " WS-EBCDIC. STOP RUN. I "assume" i could call a C or C++ routine ans use ICONV with the input codepage and output codepage acquired from a parameter in our STC. Is the parameter in the STC the best approach or am I missing something ? Regards, -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” http://secure-web.cisco.com/1qwOEDPFuoheQe1yWG1glBrfN0LjV-03LARoCV4ScHokFgCUVtDg3G28wzHmSsBUUCWkBzxJ6Zjweai-rDLSapFUUoUsnt0swsiUtTLRky3gPICD4xfJz0TwxrJxtO-VDfXDRk5b42GHlR5UgA8Uzho2ED1lSS4VxbCH5uMSH-Ylbq479rz2rbB-g-03mCgIWmp2f0UOXeFN8uhXa82cEZr6FIPy9N8r08nBfWpcdQTIFEfzTa5y9E1_R0K6VdaCPFqYaKY0VzLjBZuVAqjScK4Q0Bel1tnpIXTNbnAbJLsS43OEbZC5uuv5EzonBg9EzPhRzaljFlzn9zxO_58g8v5SaBxIOr4EFDr3oBnqPVHzzpZPU-E-pTe9mGvw3U5f1/http%3A%2F%2Fwww.idmworks.com scott.f...@idmworks.com Blog: http://secure-web.cisco.com/17EEkk6puhqHx4-OKYF5Nj8FGiYS6K8u1b_ATekR0mL5Q1TOZietQCGBKnP2DxSb_uVwZT5Hp58ytTuyKvNQ5bcmVudsVucvzuGo941Do6C8zVrUIO1ArMATxRnHhc4iYTS0GowqdXZVbIDWxfim_HMv-BAPyUAtWUPGNSs_C9M5lwbCDaZTvJdQlwCjD9XQzS9-obyAjmPiJnyI6QN18BGTk1lFKsxcJLSNy3xNqIsvO3NOcAUJugs-pIaFW1tFRXpzspBl_JBLZCfaf0AAm2mWSz3lJ4PZBPgksC7d-BRMYUAOlV9nHSmcShKYGJfkFv-QK3Q41c9cGmguO-yFA_FVMlbBMkaFiRDlwprFQN7G8_9HbK4ERKwcG5mbPMVAD/http%3A%2F%2Fwww.idmworks.com%2Fblog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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: Cobol EBCDIC to ASCII
If the data are specified as ASCII then you should be prepared to handle any code point form 0 to 127, not just alphanumeric characters. Watch out for people who write ASCII when the data aren't ASCII. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of J R Sent: Sunday, February 18, 2018 2:07 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Cobol EBCDIC to ASCII If the spec you are working to says nothing about the inbound data other than "ASCII", you should be able to assume (yes, I know) that the data contains nothing more than the basic characters 'A' to 'Z', 'a' to 'z' and '0' to '9'. No punctuation, no characters with diacritical marks, no binary fields, etc. If this does not describe your data, your spec is incomplete. Other than ASCII, what else do you know about the inbound data? Side note 1: I notice you always mention that your program runs as an STC. This is most likely irrelevant. Side note 2: I notice that you code in COBOL. If the fact that your program runs as an STC is relevant, I would recommend coding in HLASM in which control block management is more straightforward. Full disclosure: I don't even know how to spell BOLOC! > On Feb 18, 2018, at 12:50, scott Ford wrote: > > All: > > I have a question regarding inbound ASCII data. > > We read ASCII data via a EZASOKET READ call. The data is encrypted , so we > decrypt it and then > convert to EBCDIC. I looked at FTP data and there is a SBDATACON > parameter..giving both EBCDIC and ASCII ccsids or codepages. > > My problem/issue is: > > I dont know what the inbound ASCII data stream codepage is ...after a > encrypt/Decrypt using AES128 or AES256. > I have created a temporary fix to resolve it in our STC usin a CODEPAGE= > which is the ASCII codepage. > We have been using EZACIC14/15 from the IP Socket Programmer's guide. I am > looking for a univeral way to do the > conversion, I know I can do NLS and use something like below: > > CBL DBCS,NSYMBOL(NATIONAL) > IDENTIFICATION DIVISION. > PROGRAM-ID. MAIN1. > ENVIRONMENT DIVISION. > DATA DIVISION. > WORKING-STORAGE SECTION. > 01 WS-AREA PICTURE N(50). > 01 WS-CCSID PICTURE 9(5). > 01 WS-ASCII PICTURE X(50). > 01 WS-EBCDIC PICTURE X(50). > PROCEDURE DIVISION. >MOVE "ABCDE" > TO WS-EBCDIC. > DISPLAY " WS-EBCDIC = " WS-EBCDIC. >MOVE FUNCTION NATIONAL-OF(WS-EBCDIC) > TO WS-AREA. > DISPLAY " WS-AREA = " WS-AREA. >MOVE 819 TO WS-CCSID. >MOVE FUNCTION DISPLAY-OF(WS-AREA, WS-CCSID) > TO WS-ASCII. > DISPLAY " WS-ASCII= " WS-ASCII. >DISPLAY "Now let's convert that WS-ASCII back to EBCDIC". >MOVE FUNCTION NATIONAL-OF(WS-ASCII,819 ) > TO WS-AREA. > DISPLAY " WS-AREA = " WS-AREA. >MOVE 1140TO WS-CCSID. >MOVE FUNCTION DISPLAY-OF(WS-AREA, WS-CCSID) > TO WS-EBCDIC. >DISPLAY " WS-EBCDIC = " WS-EBCDIC. >STOP RUN. > > I "assume" i could call a C or C++ routine ans use ICONV with the input > codepage and output codepage acquired from a parameter in our STC. > > Is the parameter in the STC the best approach or am I missing something ? > > Regards, > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > http://secure-web.cisco.com/1tP8oquxshKCi-D7mTYK9qlYKD1x2g0B5HjVDBJ-MABfy3KHqJEqa9scOzdCJLNzjotn3gt_-j0tyqwesnqgqZF53Bky9R4n7jpuOy4HxOBeNqag_InHIbt4qt66HMpQeAs_QxUi9bMUnnHb1C8hEKsGGMZKcfmwWkB4bKVAz2uBeELF_w82I-otN5muFbSmKItArRZbYHs_HukDXbq5AjJz6pjlRUMjCR0QuS50F7T2E_X6f9AVHi-IPYhEVth0zbNVrPySsFq393V-gUvCABrPF35nk-UDjOH_0JWxzpc6HOhliURAgnkRXF4l6M1-O-VkTC7mcSN5TmJNaLsQDNKyn5KPLyNY-mEYtcz_4ncihGeAq76houD2Jb2_Uvi62/http%3A%2F%2Fwww.idmworks.com > > scott.f...@idmworks.com > > Blog: > http://secure-web.cisco.com/1p0S0AcAKEL8qtdPJyDMQ96z-voPuxWdtB8eGW0ZjnEwhYW7Ag0GnpDoGAks3yBaCvQctCNMjMmzcRY-4G-T7fyhQC4DuJSDSFdzzJlZW-Hsqf5_4H-D1Q-exORTlfHoDCZRvhWG_7cPS9HA34-lt7C41j45t_e6RRQ5TPZNnfYIwQtgdBVlOwB8WQrLGqUfLOjo6tcziK_M5LpE6j13V62CNOGCT5bFNJSYXI7yBhomCILygcUlR-Nj93tvfZI07lbwtM3zv5fw4sRLsMcG3d7Z7nD2DNntRsn-TPI-hmIpaSCpm0jxDPOc_M5k41SIMU3Jgos9aaE2kRyyWXtPwDmIFKK2iPzk2vu5AxWmvGB7i6k4Ij0xUzJo8E_5p5U4c/http%3A%2F%2Fwww.idmworks.com%2Fblog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential
Re: Cobol EBCDIC to ASCII
On Sun, 18 Feb 2018 19:07:17 +, J R wrote: >If the spec you are working to says nothing about the inbound data other than >"ASCII", you should be able to assume (yes, I know) that the data contains >nothing more than the basic characters 'A' to 'Z', 'a' to 'z' and '0' to '9'. >No punctuation, no characters with diacritical marks, no binary fields, etc. >If this does not describe your data, your spec is incomplete. > I believe "ASCII" can properly be used to refer to the first 128 characters in CCSID 819. including special characters. Informally, many use "ASCII" to refer to CCSID 819 or other ISO-LATIN code pages. If it has euro, it's probably ISO-LATIN (but which?), not ASCII. It might even be the popular UTF-8 (CP 1208), of which the first 128 code points are the same as ASCII. >Other than ASCII, what else do you know about the inbound data? > >Side note 1: I notice you always mention that your program runs as an STC. >This is most likely irrelevant. > >Side note 2: I notice that you code in COBOL. If the fact that your program >runs as an STC is relevant, I would recommend coding in HLASM in which control >block management is more straightforward. > Control blocks for socket or control blocks for iconv? >> On Feb 18, 2018, at212:50, scott Ford wrote: >> >> We read ASCII data via a EZASOKET READ call. The data is encrypted , so we >> decrypt it and then >> convert to EBCDIC. I looked at FTP data and there is a SBDATACON >> parameter..giving both EBCDIC and ASCII ccsids or codepages. >> Just curious: which? Why not transfer in binary, making SBDATACON irrelevant? The less munging the better. >> I dont know what the inbound ASCII data stream codepage is ...after a >> encrypt/Decrypt using AES128 or AES256. >> IOW, do you not know that the source codepage in SBDATACON correctly describes the original data? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol EBCDIC to ASCII
If the spec you are working to says nothing about the inbound data other than "ASCII", you should be able to assume (yes, I know) that the data contains nothing more than the basic characters 'A' to 'Z', 'a' to 'z' and '0' to '9'. No punctuation, no characters with diacritical marks, no binary fields, etc. If this does not describe your data, your spec is incomplete. Other than ASCII, what else do you know about the inbound data? Side note 1: I notice you always mention that your program runs as an STC. This is most likely irrelevant. Side note 2: I notice that you code in COBOL. If the fact that your program runs as an STC is relevant, I would recommend coding in HLASM in which control block management is more straightforward. Full disclosure: I don't even know how to spell BOLOC! > On Feb 18, 2018, at 12:50, scott Ford wrote: > > All: > > I have a question regarding inbound ASCII data. > > We read ASCII data via a EZASOKET READ call. The data is encrypted , so we > decrypt it and then > convert to EBCDIC. I looked at FTP data and there is a SBDATACON > parameter..giving both EBCDIC and ASCII ccsids or codepages. > > My problem/issue is: > > I dont know what the inbound ASCII data stream codepage is ...after a > encrypt/Decrypt using AES128 or AES256. > I have created a temporary fix to resolve it in our STC usin a CODEPAGE= > which is the ASCII codepage. > We have been using EZACIC14/15 from the IP Socket Programmer's guide. I am > looking for a univeral way to do the > conversion, I know I can do NLS and use something like below: > > CBL DBCS,NSYMBOL(NATIONAL) > IDENTIFICATION DIVISION. > PROGRAM-ID. MAIN1. > ENVIRONMENT DIVISION. > DATA DIVISION. > WORKING-STORAGE SECTION. > 01 WS-AREA PICTURE N(50). > 01 WS-CCSID PICTURE 9(5). > 01 WS-ASCII PICTURE X(50). > 01 WS-EBCDIC PICTURE X(50). > PROCEDURE DIVISION. >MOVE "ABCDE" > TO WS-EBCDIC. > DISPLAY " WS-EBCDIC = " WS-EBCDIC. >MOVE FUNCTION NATIONAL-OF(WS-EBCDIC) > TO WS-AREA. > DISPLAY " WS-AREA = " WS-AREA. >MOVE 819 TO WS-CCSID. >MOVE FUNCTION DISPLAY-OF(WS-AREA, WS-CCSID) > TO WS-ASCII. > DISPLAY " WS-ASCII= " WS-ASCII. >DISPLAY "Now let's convert that WS-ASCII back to EBCDIC". >MOVE FUNCTION NATIONAL-OF(WS-ASCII,819 ) > TO WS-AREA. > DISPLAY " WS-AREA = " WS-AREA. >MOVE 1140TO WS-CCSID. >MOVE FUNCTION DISPLAY-OF(WS-AREA, WS-CCSID) > TO WS-EBCDIC. >DISPLAY " WS-EBCDIC = " WS-EBCDIC. >STOP RUN. > > I "assume" i could call a C or C++ routine ans use ICONV with the input > codepage and output codepage acquired from a parameter in our STC. > > Is the parameter in the STC the best approach or am I missing something ? > > Regards, > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > 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
