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

Thanks for the explanation; I understand it for the most
part.

However I do have a few more questions.

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?

2) Somehow translate the EBCDIC field contain "Hello" to
ASCII then encode it to Base64. To get the Base64 value the
ASCII machine is looking for.

3) Store the value "Hello" in a file in the IFS, Encode it
to Base64 and sent it to the ASCII machine?

I would prefer #1, is any of this possible?
Or am I totally confused?

John



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

Hi John,

The purpose behind base64 is to allow binary data to be sent
through a
text transfer medium. For example, if you have a JPEG
picture and want
to send it through e-mail, you have a problem. Pictures
aren't made up
of letters and numbers, instead the actual bit values of the
bytes
control what the picture looks like. However, e-mail was
designed for
text. If you send e-mail from a computer running ASCII to a
computer
running EBCDIC, all of the bytes in the message will be
translated from
ASCII to EBCDIC -- so a picture would become a corrupt mess.

Base64 is a solution to that problem. Base64 takes the
actual bit
values that make up a string of data, and converts them to
to a
text-safe format. The text can then be translated to
ASCII/EBCDIC/Unicode, whatever, it doesn't matter. When
it's decoded,
the data will be decoded back to the exact same binary
values that you
started with.

That being the case, a text string encoded on an EBCDIC
platform will
CERTAINLY encode to a different string than a text string
encoded on an
ASCII platform! Of course it will, since the underlying
bit values are
different.

If you take the string 'Hello' and encode it on an EBCDIC
platform,
you've encoded x'C885939396' into base64. When you decode
it on an
ASCII platform, it'll decode to x'C885939396' -- which is
NOT the word
Hello in ASCII (If it did that, there'd be no point to
base64) but
rather, it's the exact same bit values you started with...

Hope you understand.

John Allen wrote:
I am doing a test to see of I can convert a character
string
to B64 from within an RPG program

There are programs on the web that convert files in the
IFS,
but I need to convert a database field



So I am using a B64 encode/decode program from Scott
Klement
(Thanks Scott)

However I am getting a completely different value then
what
I get using a Web based B64 encode decode program

AND when I try to convert it back it does not convert back
correctly



Can anyone point me to what I may be doing wrong?

Does the encode.decode expect ASCII characters?

Should the example below work fine?



W$Before = 'ABCDEFGH';



W$AfterLen = B64_Encode( %ADDR(W$Before)

: %LEN(%TRIMR(W$Before))

: %ADDR(W$After)

: %SIZE(W$After) );



(Using Debug I see that W$AFTER = 'wsLDxcXGxMgg')

(Web based encodes to QUJDREVGR0gNCg==)



W$AfterLen2 = B64_Decode( %ADDR(W$After)

: %LEN(%TRIMR(W$After))

: %ADDR(W$After2)

: %SIZE(W$After2) );





(Using Debug I see that decodes back to W$AFTER2 =
'BBCEEFDH- ')



Any ideas on what I might be doing wrong?



Thanks



John







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.