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



No you shouldn't use type B(binary)...

Actually, you should never use it. It's left over from before RPG had true
integer support.

Remember it's a computer, everything is binary. That's all that computers
understand.

The binary value in a particular 4 bytes of memory is interpreted as a
number if you've told the compiler it's an integer. But the same binary
value would be interpreted as 4 characters if you've told the compiler it's
a character.

Let's say the data, "HELLO" was base64 encoded on an ASCII system, when you
decode it, you'll have x'48454C4C4F' which is the ASCII value for that
string. To display it on the EBCDIC IBM i, you'd want it converted to
x'C8C5D3D3D6'.

Now having said that, what do you mean "I'll be applying this code to send
a device token"?

If you're using this value as part of a hash or encryption or just sending
it back out to an ASCII system, then you most definitely want to leave it
alone. Treating it like a character string and converting to ASCII will
change the binary values as shown in my example. In this case, just define
a memory buffer to hold whatever you've been given. RPG doesn't have
a separate "byte array" type like Java does; Best we can do is a character
field of X characters.

If you wanted to store it in the DB, you should define the field as CHAR()
FOR BIT DATA (when using SQL DDL) or tag it with CCSID 65535 when using
DDS;. Both of which tells the DB not to try to interpret the value as a
displayable character string.






On Tue, Apr 7, 2015 at 8:23 AM, <RWesh@xxxxxxxxxxx> wrote:

Thank you Scott

I was actually noticing that I kept consistently getting blank output when
using varying fields so this should help.

The EBCDIC also might explain why I get something that looks like
gibberish on the display when I do get output.

I do have another question. Base64 decode is decoding the value back to
its binary form correct?

Technically should my output variable be of type B(binary) instead of a
character string?

Ultimately, I'll be applying this code to send a device token

Russell Wesh, PMP | Data Integration Specialist
Sumitomo Drive Technologies
Sumitomo Machinery Corp. of America
Tel: +1-757-485-3355 ext. 8633
Cell: +1-757-822-4446
Fax: +1-757-485-7190
www.sumitomodrive.com | How are we doing?



From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>
Date: 04/06/2015 05:24 PM
Subject: Re: Base64 Decode Help
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>




One more wrinkle to this... to get the length right on the otuput
field, you'll need to start by expanding it to it's full size, then
shrinking it back to only the size you're using.

So you'd do this on recent releases:

%len(W#TKN2) = %len(W#TKN2:*MAX);

len = base64_decode( %addr(W#TKN:*DATA)
: %len(%trimr(W#TKN))
: %addr(W#TKN2:*DATA)
: %len(W#TKN2:*MAX) );

%len(W#TKN2) = len;

Or, on older releases you'd do this:

%len(W#TKN2) = %size(W#TKN2) - 2;

len = base64_decode( %addr(W#TKN) + 2
: %len(%trimr(W#TKN))
: %addr(W#TKN2) + 2
: %size(W#TKN2) - 2 );

%len(W#TKN2) = len;

I don't know whether the %trimr() on the 2nd line is really needed, that
depends on whether there are trailing blanks in W#TKN, but it shouldn't
hurt anything.

Also keep in mind that base64 preserves the binary value of the string.
So if your data was originally text data that was encoded in ASCII,
UTF-8, or something like that, the output will still be in ASCII or
UTF-8, or whatever. So if it is indeed text that you want to have in
EBCDIC, you'll need to convert it after you decode it.

-SK





On 4/6/2015 2:59 PM, Scott Mildenberger wrote:
Since they are varying you can't just use %addr of the field, you need
%addr(W#TKN : *data) so it points to the actual data part of the field
bypassing the length portion at the beginning. If you are not at a new
enough release use %addr(W#TKN : 2) instead. Do that for both fields in
the call.

Scott Mildenberger


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
RWesh@xxxxxxxxxxx
Sent: Monday, April 06, 2015 1:54 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Base64 Decode Help

Apologies

D rc S 10U 0
D W#TKN S 50a varying
D W#TKN2 S 50a varying

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


Email scanned & secured by the Sumitomo Chesapeake CheckPoint Firewall.





This document should only be read by those persons to whom it is addressed
and is not intended to be relied upon by any person without subsequent
written confirmation of its contents. Accordingly, Sumitomo Machinery
Corporation disclaims all responsibility and accept no liability (including
in negligence) for the consequences for any person acting, or refraining
from acting, on such information prior to the receipt by those persons of
subsequent written confirmation. If you have received this e-mail message
in error, please notify us immediately by telephone. Please also destroy
and delete the message from your computer. Any form of reproduction,
dissemination, copying, disclosure, modification, distribution and/or
publication of this e-mail message is strictly prohibited.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



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.