Home > Archive > Cobol > July 2006 > EBCDIC to ASCII
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi,
Is it possible to change the charset of a data file (i.e., from EBCDIC
to ASCII)? If yes, pls let me know how its done.
| |
|
| In article <1152549530.707470.50370@p79g2000cwp.googlegroups.com>,
Zeta <jeevitha.k@gmail.com> wrote:
>Hi,
>Is it possible to change the charset of a data file (i.e., from EBCDIC
>to ASCII)? If yes, pls let me know how its done.
It might be possible, yes. Please post what you have done so far in order
to decrease the possibility of duplicating errors.
DD
| |
| Howard Brazee 2006-07-10, 6:55 pm |
| On 10 Jul 2006 09:38:50 -0700, "Zeta" <jeevitha.k@gmail.com> wrote:
>Hi,
>Is it possible to change the charset of a data file (i.e., from EBCDIC
>to ASCII)? If yes, pls let me know how its done.
There are ways, as long as the data are stored in character format. My
preferred method is to make sure the data are all stored with external
signs, DISPLAY format, etc., and then let the FTP make the conversion.
It doesn't seem to me that CoBOL is the best tool for this when FTP
works so well.
| |
| Michael Mattias 2006-07-10, 6:55 pm |
| "Howard Brazee" <howard@brazee.net> wrote in message
news:su15b2ptbg51957lfi0993p9lmea04hm5s@
4ax.com...
> On 10 Jul 2006 09:38:50 -0700, "Zeta" <jeevitha.k@gmail.com> wrote:
>
>
> There are ways, as long as the data are stored in character format. My
> preferred method is to make sure the data are all stored with external
> signs, DISPLAY format, etc., and then let the FTP make the conversion.
Actually you CAN convert from EBCDIC to ASCII even if the data are USAGE
BINARY or USAGE PACKED-DECIMAL or USAGE COMP-1.... it's just that you
SHOULDN'T in this case
How to know when to convert and when not to do so...
http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm
MCM
| |
| epc8@juno.com 2006-07-10, 6:55 pm |
| Michael Mattias wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:su15b2ptbg51957lfi0993p9lmea04hm5s@
4ax.com...
>
>
> Actually you CAN convert from EBCDIC to ASCII even if the data are USAGE
> BINARY or USAGE PACKED-DECIMAL or USAGE COMP-1.... it's just that you
> SHOULDN'T in this case
>
> How to know when to convert and when not to do so...
>
> http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm
>
>
> MCM
You could still get into trouble keeping the data in EBCDIC during a
file transfer.
A few years ago I FTPed some help files from a mainframe using the
default binary transfer mode. I was not able to make sense of these
files at all. I did have a program that translated that flavor of
EBCDIC to ASCII. But this was to no avail. The ASCII text was there but
there were no line breaks (cr/lf). The original was variable length
records so I could not just add line delimiters as if these were fixed
length records. I had to set text mode in my FTP program and grab the
files again. :-(.
-- elliot
| |
| Michael Mattias 2006-07-10, 6:55 pm |
| <epc8@juno.com> wrote in message
news:1152556690.550380.86750@p79g2000cwp.googlegroups.com...
> Michael Mattias wrote:
>
> You could still get into trouble keeping the data in EBCDIC during a
> file transfer.
>
> A few years ago I FTPed some help files from a mainframe using the
> default binary transfer mode...The ASCII text was there but
> there were no line breaks (cr/lf)...
I had one a couple of years ago (before 'FTP' was common) where there was a
HARDWARE EBCDIC-ASCII conversion done by the communications software. Oops,
one of the byte translations was wrong.
That's the problem when you go through so many layers of software.
All the automatic/default "help" you get at each step is what totally
cheeses up your data.
In this kind of situation, better IMO to just bite the bullet and write
something where YOU control everything.
MCM
| |
| Howard Brazee 2006-07-10, 6:55 pm |
| On Mon, 10 Jul 2006 19:49:11 GMT, "Michael Mattias"
<michael.mattias@gte.net> wrote:
>
>I had one a couple of years ago (before 'FTP' was common) where there was a
>HARDWARE EBCDIC-ASCII conversion done by the communications software. Oops,
>one of the byte translations was wrong.
>
>That's the problem when you go through so many layers of software.
>
>All the automatic/default "help" you get at each step is what totally
>cheeses up your data.
>
>In this kind of situation, better IMO to just bite the bullet and write
>something where YOU control everything.
I disagree. Simplify the data so that it can be handled by the FTP.
Do not do binary FTPs between EBCDIC and ASCII machines.
| |
|
| In article <Xaysg.1842$2v.225@newssvr25.news.prodigy.net>,
Michael Mattias <michael.mattias@gte.net> wrote:
[snip]
>That's the problem when you go through so many layers of software.
>
>All the automatic/default "help" you get at each step is what totally
>cheeses up your data.
>
>In this kind of situation, better IMO to just bite the bullet and write
>something where YOU control everything.
Is it my imagination or can the above be translated to 'don't trust to the
bugs written in other layers of software, trust to the bugs written in
your *own* layer of software'?
DD
| |
| hcmason@sbcglobal.net 2006-07-10, 6:55 pm |
| Hi Zeta:
Keep in mind some EBCDIC characters won't translate into standard
ASCII.
For example, the penny sign (not on the PC keyboard) that was once on
the typewriter
to represent cents was never added to standard ASCII. I did find it on
some extended ASCII code pages, but not on the first 127 ASCII codes.
Besides that, be sure to make your numerics character based with
seperate signs.
Or if you never have negatives, just skip the signs...
Ebcdic signed fields sometimes look like letters or braces.
01 DATA-ITEM3 PIC S9(3) VALUE IS +123 SIGN IS LEADING X'4EF1F2F3'
SEPARATE CHARACTER.
This will result in a 4 bytes record.
The hex code 4E is + in EBCDIC. F1 is 1 in EBCDIC. etc...
Zeta wrote:
> Hi,
> Is it possible to change the charset of a data file (i.e., from EBCDIC
> to ASCII)? If yes, pls let me know how its done.
| |
| William M. Klein 2006-07-10, 6:55 pm |
| I don't know if we ever found out where/why the OP was asking this.
If (and only if <G> ) you are running on an IBM mainframe compiler - with a
currently supported compiler, you can read in an EBCDIC file and create an ASCII
version of it via "MOVE CORR" and writing it. When creating the output file you
must do ALL of the following:
1) Write the output file to TAPE (not DISK) Check for the correct DCB parameter
for ASCII OUTPUT
2) Define all numeric fields (implicitly or explicitly) as USAGE DISPLAY - and
with SIGN IS SEPARATE
3) Use the CODE-SET phrase in your output to specify "STANDARD-1" (pr -2)
***
If you happen to be working FROM an IBM mainframe to a PC *and* if you have a
Micro Focus Workbench or MFEEE product, look for a utility that provides
conversion (and will even let you "keep" data as COMP-whatever).
I believe that CA-Realia has a similar utility, but don't know about IBM, RM, or
Fujitsu.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
|
| In article <0KBsg.172805$wA1.19976@fe03.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>I don't know if we ever found out where/why the OP was asking this.
Seems to me there's been a couple-three like that recently, aye... a
question to which someone responds 'show your work' and a bunch of other
folks discussing possible solutions in a vacuum, sort of.
DD
| |
| Michael Mattias 2006-07-11, 7:55 am |
| <docdwarf@panix.com> wrote in message news:e8umar$7f1$1@reader2.panix.com...
> In article <Xaysg.1842$2v.225@newssvr25.news.prodigy.net>,
> Michael Mattias <michael.mattias@gte.net> wrote:
>
> [snip]
>
>
> Is it my imagination or can the above be translated to 'don't trust to the
> bugs written in other layers of software, trust to the bugs written in
> your *own* layer of software'?
ABSOLUTELY!
MCM
| |
|
| In article <xeMsg.63754$fb2.31386@newssvr27.news.prodigy.net>,
Michael Mattias <michael.mattias@gte.net> wrote:
><docdwarf@panix.com> wrote in message news:e8umar$7f1$1@reader2.panix.com...
[snip]
>
>
>ABSOLUTELY!
Oh boy... I got one right, maybe I should mark a calendar, somewhere.
DD
| |
| epc8@juno.com 2006-07-11, 6:55 pm |
| docdwarf@panix.com wrote:
> In article <0KBsg.172805$wA1.19976@fe03.news.easynews.com>,
> William M. Klein <wmklein@nospam.netcom.com> wrote:
>
> Seems to me there's been a couple-three like that recently, aye... a
> question to which someone responds 'show your work' and a bunch of other
> folks discussing possible solutions in a vacuum, sort of.
>
> DD
Or could it be that some posters have such a great grasp of net
etiquette that they do not bother with a simple reply? <mild sarcasm>
>From time to time I do find the lack of follow up a bit bothersome.
-- elliot
| |
|
| > Hi,
> Is it possible to change the charset of a data file (i.e., from EBCDIC
> to ASCII)? If yes, pls let me know how its done.
At some point this data is on the mainframe since you're converting
from EBCDIC. I just do this on the EBCDIC fields. XLATE is the IBM
system macro designed for code conversions. Fast because it executes an
SVC, simple and reliable. DO NOT attempt to convert binary or
packed data as that is NOT EBCDIC and will be destroyed.
TITLE 'CONVERT FROM EBCDIC TO ASCII'
EB2AS CSECT
EB2AS AMODE 31
EB2AS RMODE ANY
*
* EXAMPLE FROM COBOL:
* 05 CONVERT-LENGTH PIC S9(9) COMP.
* 05 CONVERT-FIELD PIC X(30). (CAN BE ANY FIELD, ANY LENGTH)
*
* MOVE LENGTH OF CONVERT-FIELD TO CONVERT-LENGTH.
* CALL 'EB2AS' USING CONVERT-LENGTH CONVERT-FIELD.
*
YREGS
*
USING *,R3
STM R14,R12,12(R13)
LR R3,R15
ST R13,SAVEAREA+4
LA R12,SAVEAREA
ST R12,8(0,R13)
LR R13,R12
LM R4,R5,0(R1) R4=LENGTH R5=DATA
L R4,0(R4)
XLATE (R5),(R4),TO=A
GOBACK L R13,SAVEAREA+4
LM R14,R12,12(R13)
LA R15,0
BR R14
*
SAVEAREA DC 18F'0'
*
END
| |
| Joe Zitzelberger 2006-07-12, 9:55 pm |
| In article <1152549530.707470.50370@p79g2000cwp.googlegroups.com>,
"Zeta" <jeevitha.k@gmail.com> wrote:
> Hi,
> Is it possible to change the charset of a data file (i.e., from EBCDIC
> to ASCII)? If yes, pls let me know how its done.
There are a number of ways:
You could try a copy with the ASCII file defined with TRTCH=Q -- but
that requires specific devices.
You could use the functions Display-Of and National-Of to convert from
1140 to 437 or whatever specific sets you need.
You could call the TCP/IP translations programs EZA???04 and EZA???05.
You could code an inspect/converting with both charsets in hex notation.
There are lots of ways...
|
|
|
|
|