While my original logic worked fine with the TEST web service, the real world implementation failed after successfully working for 20+ transactions.
To summarize... I am consuming a SOAP web service (with HTTPAPI's http_post_xml) that returns an XML element containing BASE 64 encoded ZPLII (Zebra printer) data.
I need to:
1. Decode the data
2. Write the decoded data to the IFS as a text file (preferably in a common format like UTF8)
3. Send that text file directly to the Zebra Printer (I'm using Scott's PRTSTMF utility for that)
Message . . . . : An error occurred during conversion from CCSID(1208) to
CCSID(937).
My code looks like this (currently in my "EndOfElement" callback for http_post_xml):
dcl-s base64encoded varchar(65535) inz;
dcl-s base64decodedUTF char(65535) ccsid(*utf8) inz;
// dcl-s base64decodedUTF char(65535) inz;
dcl-s len uns(10) inz;
when name = 'Base64LabelImage';
base64Encoded = value;
len = base64_decode( %addr(base64Encoded:*data)
: %len(%trim(base64Encoded))
: %addr(base64DecodedUTF)
: %size(base64DecodedUTF)
);
GetLabelResponse.label(lbl) = %subst(base64DecodedUTF:1:len); // this is where I receive the CCSID error above.
In debug, I can take the values of "value" and/or base64Encoded variables and paste them into an online decoder - it works fine. Even with the data that produced the error above.
But the decoding is what is failing (not the write to IFS). If the variable "base64decodedUTF" is set to CCSID(*UTF8), it worked most of the time (until I received the error above).
If I define "base64decodedUTF" WITHOUT the CCSID(*UTF8), the length is much larger and I cannot "see" the data value in debug (or write it to the IFS).
I'm doing something wrong... but what??
Greg
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, July 20, 2020 5:12 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Base64 decode
Greg,
If you need to use a CCSID(1208) field to write to the IFS, then you are
using the IFS APIs incorrectly.
Since you know your data is in CCSID 1208, tell the open API that the
data is CCSID 1208 and that it should not perform translation for you.
This will cause the file to be created successfully. It does not matter
what the CCSID of your RPG field is in that case.
-SK
On 7/20/2020 4:00 PM, Greg Wilburn wrote:
Scott,
Thanks... it definitely was encoded. I copied the 40K string and placed it into an online decoder.
Decoded, it represents ZPL (Zebra Printer Language) for a label.
Once I changed the CCSID of the field DECODED to 1208 (to match the incoming data), I was able to write it out to an IFS file.
Before doing so (assuming the DECODED field was 37) the IFS file was illegible.
It must be something with RDi and displaying the resulting field... I know RDi gets unstable when trying to view large character variables while in debug. That is what prompted me to write out the result to a stream file. In this case, it may be useful to keep it (to reprint a USPS label w/out having to call the web service again).
midrange.com
