convert ascii to ebcdic

[lori]

in a mainframe COBOL II program, what's the best way to convert an
ASCII file to an EBCDIC file? Is there a "clever" way, or is it just
read a translation table? TIA.
lorig...@hotmail.com

[Binyamin Dissen]

On 23 Sep 2003 12:19:16 -0700 lorig...@hotmail.com (lori) wrote:

:>in a mainframe COBOL II program, what's the best way to convert an

:>ASCII file to an EBCDIC file? Is there a "clever" way, or is it just
:>read a translation table? TIA.

There is a DCB option (OPTCD=Q if I recall correctly) which does it
automagically.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

[Simeon Nevel]

"lori" <lorig...@hotmail.com> wrote in message
news:4dc738b.03092...@posting.google.com...

> in a mainframe COBOL II program, what's the best way to convert an
> ASCII file to an EBCDIC file? Is there a "clever" way, or is it just
> read a translation table? TIA.

Conversion of signed numerics, floats and packed fields are a bit tricky

See:

http://www.discinterchange.com/TechTalk_signed_fields.html

Simeon

[Ron]

> in a mainframe COBOL II program, what's the best way to convert an
> ASCII file to an EBCDIC file? Is there a "clever" way, or is it just
> read a translation table? TIA.

This question comes up SO often. I just don't understand they don't
have a "function ascii", "function ebcdic" to convert data on a field
by field basis!!!

[Michael Mattias]

"Ron" <No...@swbell.net> wrote in message
news:i8icnfZpDpx...@giganews.com...

Real simple reason... both ASCII and EBCDIC are subject to local (well,
national) variations.

Besides, if there were such functions the tutorial I wrote on this subject
and make available (FREE) for all at my web site at...

http://www.talsystems.com/tsihome_html/downloads/C2IEEE.htm

.. would never have happened!

--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmat...@talsystems.com

[William M. Klein]

Such a good idea that it has been available for several years now. See:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/1.6.6.4

UNFORTUNATELY, this isn't a solution for this person - who is "still" on
(the currently unsupported) VS COBOL II compiler.

--
Bill Klein
wmklein <at> ix.netcom.com

"Ron" <No...@swbell.net> wrote in message
news:i8icnfZpDpx...@giganews.com...

[William M. Klein]

Yes, OPTCD=Q will work - but requires that the ASCII file be on TAPE.

However, as others have pointed out, there will be problems if you have any
non-display fields or numeric fields without sign is separate.

If the INTENT is to move from the mainframe to the PC (or Unix) then there
are tools to use a "record" layout for doing an intelligent conversion. I
know that Micro Focus has such a tool - and I think some of the other PC
vendors do too.

--
Bill Klein
wmklein <at> ix.netcom.com

"Binyamin Dissen" <post...@dissensoftware.com> wrote in message
news:rq71nv01e6a4err09...@4ax.com...

[Howard Brazee]

On 23-Sep-2003, lorig...@hotmail.com (lori) wrote:

> in a mainframe COBOL II program, what's the best way to convert an
> ASCII file to an EBCDIC file? Is there a "clever" way, or is it just
> read a translation table? TIA.

My preferred method is to let FTP handle it as it is transferred to the
mainframe.

[Ron]

> Such a good idea that it has been available for several years now. See:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/1.6.6.4
>
> UNFORTUNATELY, this isn't a solution for this person - who is "still" on
> (the currently unsupported) VS COBOL II compiler.
>
> --

Hmmm, interesting. I shall have to file this for future reference.
I wouldn't exactly call this an intuitive solution though. An obtuse
solution would be more like it. I still think an actual 'function
ascii' and 'function ebcdic' that you coded similar to 'function
upper-case' would be much more straightforward.
... just my opinion.

[Ron]

> > This question comes up SO often. I just don't understand they don't
> > have a "function ascii", "function ebcdic" to convert data on a field
> > by field basis!!!
>
> Real simple reason... both ASCII and EBCDIC are subject to local (well,
> national) variations.

But then so would be function upper-case, function national-of etc.
Conversions should take place using the appropriate code pages installed
on the executing machine irrespective of national variations.

> Besides, if there were such functions the tutorial I wrote on this subject
> and make available (FREE) for all at my web site at...
>
> http://www.talsystems.com/tsihome_html/downloads/C2IEEE.htm
>
> .. would never have happened!

Interesting page but I couldn't look at it for more than 45 seconds.
Please change the background color. That yellow is too hard on the eyes
and made me feel queasy.

[William M. Klein]

When/if IBM ever implements the entire 2002 COBOL Standard, this would be
quite easy to do with a "user-defined" function. The user could do what the
sample (in the programming guide) does - but use your "intuitive" syntax.

Of course, they would have to know WHICH EBCDIC was in use (if you didn't
know - it varies from country to country - where alphabets have "additional"
characters)

P.S. It is interesting to note that what IBM has implemented as intrinsic
functions for NATIONAL-OF and DISPLAY-OF is incompatible with the 2002
Standard. Therefore, any applications that use the 2nd parameter of the
existing IBM implementations will have migration problems when/if IBM *does*
provide a fully conforming 2002 compiler. I (personally) have never
understood WHY they made this "incompatible" decision, but they did - so
some day some "of us" can look forward to upward compatibility problems
and/or migration issues.

--
Bill Klein
wmklein <at> ix.netcom.com
"Ron" <No...@swbell.net> wrote in message

news:l6-dnbukb8E...@giganews.com...

[Frank Swarbrick]

Or in COBOL for VSE/ESA, apparently...

>>> William M. Klein<wmk...@nospam.netcom.com> 09/23/03 05:20PM >>>