Re: [Ftpapi] At my wits end

On Thu, Nov 19, 2020 at 11:17 AM Thomas Raddatz <thomas.raddatz@xxxxxxxxxxx> wrote:

Hi Braden,

The ccsid of your variable does not matter, when you read data from an
IFS file in binary mode, because you would pass the pointer of the
variable to the read() function.

But of course it would take effect, when you assign the value of that
variable to another variable. I would use a variable with the ccsid of
the IFS stream file and pass that on to the base64 encoder.

Then you should be able to concatenate the result of the base64 encoder
to the soap message.

Maybe I can create a little demo program, tomorrow.

Thomas.

Am 18.11.2020 um 16:12 schrieb Braden Lincoln:
> Thanks, Thomas.
>
> In my RPG program, does it matter what the ccsid of the variables I use
> to feed to and/or receive the response from the base64 encoder? Is the
> job ccsid of any importance? I did run into issues (ccsid conversion
> error) building the soap envelope when trying to concatenate text data
> and the contents of the encoded data.
>
> I will probably start from a fresh sheet and try to use the information
> you provided. I will avoid the IFS, and just string the data together,
> translate to UTF-8, then encode to base64 and stuff it into the soap
> envelope and see what happens.
>
> I do appreciate your response.
>
> Braden Lincoln
>
> I do appreciate your response.
>
> On Tue, Nov 17, 2020 at 10:55 PM Thomas Raddatz <thomas.raddatz@xxxxxx
> <mailto:thomas.raddatz@xxxxxx>> wrote:
>
> The base64 service program does not care anything about the ccsid of
> the input/output data. It also does not know anything about ASCII or
> EBCDIC.____
>
> __ __
>
> It just takes the input data as a stream of bytes and encodes them
> to BASE64. The hex values of the characters of a Base64 stream (the
> encoded data), are the same for all code pages. Hence they can be
> decoded to the original data on every system, regardless of the code
> page of that system.____
>
> __ __
>
> When you wrote your data to an IFS file with code page 819, how did
> you read it? Did you read it as a binary data or text data? When you
> read it as text data, then it has been converted back to EBCDIC in
> your program and you did not won anything.____
>
> __ __
>
> The same is with SQL function SYSTOOLS.BASE64ENCODE(). You need to
> convert your data to the target code page (most likely utf-8 or 819)
> before encoding it to Base64.____
>
> __ __
>
> You may check the IBM ivonc() function or Scott’s HTTP_xlatedyn()
> for converting your data to utf-8 before passing it to
> Base64_encode() or the SQL function.____
>
> __ __
>
> You can check the result of the encoding operation with one of the
> various online encoders/decoders, such as
> https://www.base64decode.org/ <https://www.base64decode.org/>.____
>
> __ __
>
> Thomas.
> ____
>
> *Von:*ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx>
> <ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx>> *Im Auftrag von
> *Braden Lincoln
> *Gesendet:* Dienstag, 17. November 2020 15:40
> *An:* FTPAPI/HTTPAPI mailing list <ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx>>
> *Betreff:* Re: [Ftpapi] At my wits end____
>
> __ __
>
> Thanks, Kevin, but I tried that approach as well. Moved my base64
> encoding to the point after I wrote/read the file from IFS. Same
> issue. Maybe 819 isn't the code page I should be using? But
> Somehow I thought I had seen comments floating in the internet that
> the base64 encoding service program was meant to be used with EBCDIC
> data. I could be mistaken. I also tried sending the string just
> after encoding to base64, without writing to IFS and reading again.
> Same bad result.____
>
> __ __
>
> On Tue, Nov 17, 2020 at 6:31 AM Kevin Bucknum
> <Kevin@xxxxxxxxxxxxxxxxxxx <mailto:Kevin@xxxxxxxxxxxxxxxxxxx>>
> wrote:____
>
> It will need to be ASCII/UTF/etc before you encode it. Translate
> it before you base64 encode it.____
>
> __ __
>
> On Tue, 2020-11-17 at 06:09 -0800, Braden Lincoln wrote:____
>
> Hoping someone can help. I have overcome all the
> connectivity issues with this SOAP web service I am
> connecting to. And I can even send the file payload. But
> the encoding of the data is just wrong, and I can't seem to
> find the magic solution. ____
>
> __ __
>
> I've tried sending the raw data as a string. Server rejects
> it immediately with http 500 error. It suggested it was not
> "properly base64 encoded data". So, I downloaded and
> installed the BASE64 encoding service program from Scott. I
> encoded the string, and it went through, http 200, we
> thought we were home free. But the data on the receiving
> server was garbled - apparently not encoded in a way that
> they could decode it correctly. I thought maybe it was an
> EBCDIC/ascii issue, so i decided to write the encoded string
> to the IFS using code page 819, then read it back in and
> send it. Same result.____
>
> __ __
>
> I've tried every which way I can think of (which is
> apparently just short of enough). I need some expert advice
> on how to get this string to the receiver correctly.____
>
> __ __
>
> Attached are the program source, the http log (where the
> request string can be seen), and the garbled mess from the
> receiving server. Hoping for some sage advice. Thanks in
> advance. ____
>
> __ __
>
> *https://www.medtronsoftware.com/img/MedtronMinilogo.bmp**Kevin  Bucknum*
>                    Senior Programmer Analyst
> *                   MEDDATA** / MEDTRON*
>                    120 Innwood Drive
>                    Covington LA 70433
>                    Local: 985-893-2550
>                    Toll Free: 877-893-2550
> https://www.medtronsoftware.com
> <https://www.medtronsoftware.com>____
>
> __ __
>
> *CONFIDENTIALITY NOTICE*____
>
> *This document and any accompanying this email transmission
> contain confidential information, belonging to the sender that
> is legally privileged. This information is intended only for
> the use of the individual or entity named above. The authorized
> recipient of this information is prohibited from disclosing this
> information to any other party and is required to destroy the
> information after its stated need has been fulfilled. If you
> are not the intended recipient, or the employee of agent
> responsible to deliver it to the intended recipient, you are
> hereby notified that any disclosure, copying, distribution or
> action taken in reliance on the contents of these documents is
> STRICTLY PROHIBITED. If you have received this email in error,
> please notify the sender immediately to arrange for return or
> destruction of these documents.*____
>
> --
> _______________________________________________
> Ftpapi mailing list
> Ftpapi@xxxxxxxxxxxxxxxxxxxxxx <mailto:Ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> http://scottklement.com/mailman/listinfo/ftpapi
> <https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url="">>____
>
> --
> _______________________________________________
> Ftpapi mailing list
> Ftpapi@xxxxxxxxxxxxxxxxxxxxxx <mailto:Ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> http://scottklement.com/mailman/listinfo/ftpapi
> <http://scottklement.com/mailman/listinfo/ftpapi>
>
>
--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi