× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott,

Maybe I have something wrong in my test code:
I am testing with "ABC"
I translate this to ASCII and get the correct value
X'414243'
I do Base64 encode and get QkJD
Then when I decode it I get X'424243'
Which is BBC

D W$Before S 8A
D W$After S 12A
D W$AfterLen S 10I 0
*
D W$After2 S 12A
D W$AfterLen2 S 10I 0
*
D P$LEN S 4 0
D P$Table S 10A
*
C eval W$Before = 'ABC'
* Calculate length of PCL commnd string
C ' ' CHECKR W$Before P$Len
* Convert string to ascii
C CALL 'QDCXLATE'
C PARM P$len
C PARM W$Before
C PARM 'QASCII' P$table
*
* W$Before = 'ABC'; after translation debug shows x'414243'

/free

W$AfterLen = B64_Encode( %ADDR(W$Before)
: %LEN(%TRIMR(W$Before))
: %ADDR(W$After)
: %SIZE(W$After) );

W$AfterLen2 = B64_Decode( %ADDR(W$After)
: %LEN(%TRIMR(W$After))
: %ADDR(W$After2)
: %SIZE(W$After2) );

*INLR = *ON;
/end-free

WAfter2 = debug shows x'424243' (which is BBC)



-----Original Message-----
From: Scott Klement [mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Thursday, November 06, 2008 3:13 PM
To: Midrange Systems Technical Discussion
Subject: Re: Base64 question

hi John,

I don't think it makes sense to store in ASCII in the
database. After
all, you're likely to want to do other things with your
database besides
this one program.

Why not just add code to your RPG program to convert it to
ASCII prior
to base64 encoding it?

Here's a trivial example in ILE RPG, that uses the
IBM-supplied QDCXLATE
program to convert from EBCDIC to ASCII:

D QDCXLATE PR
ExtPgm('QDCXLATE')
D Len 5p 0 const
D data 32702a
options(*varsize)
D table 10a const

D data s 5
/free
data = 'Hello';
QDCXLATE( %len(data)
: data
: 'QTCPASC' );

The above method is really easy to do, and it works. It can
be used with
any of the translation tables (*TBL objects) on your system.
QTCPASC is
an IBM-supplied table that translates to ASCII.

There are two big problems with QDCXLATE:

a) You can't use it to translate a single-byte character set
to a double
or mixed-byte character set.

b) In order to make it work properly with variant
characters, you have
to find (or create) a table that translates exactly the way
you want.
(there are many versions of ASCII and many versions of
EBCDIC. Which
one are you translating from? Which one are you translating
to?)

A more sophisticated method of doing the translation (and
one that
requires more code) is to use the iconv() API. With iconv()
you can
provide the exact from/to CCSID and it'll translate between
them. It
also lets you work with double-byte and multi-byte character
sets. But
the code is more complex, so I'll leave you with the
QDCXLATE API for
now, and if you find that lacking, let me know and I'll post
an iconv
example.

But, at any rate, ASCII/EBCDIC translation is hardly part of
Base64
encoding! Indeed, most of the time you use base64 encoding
expressly
because your data isn't text data!



John Allen wrote:

1)If I have the value "Hello" in my database field on the
System i (in EBCDIC) isn't there some method I can convert
it to an ASCII value before encoding it to Base64 so I end
up with the correct Base64 value the ASCII machine is
expecting, or just store it in my database field in ASCII
format (although it is actually an EBCDIC System)?
Example If the value were 123 in EBCDIC it would be stored
as x'F1F2F3' Could I store it as ASCII x'313233' then
could
it be encoded to Base64 to be read in correctly by ASCII
system?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.