Hi Scott,
I sent the following two problem reports to the mailing list, yesterday. They still do not yet show up in the list. Is there something wrong with the mailing list?
Best Regards,
Thomas.
Problem report #1:
I noticed a problem with the ccsid of the response file when using http_req(). The problem is that the file ccsid is not properly set, when the default had been set with HTTP_SetFileCCSID().
http_req() uses 'global.file_ccsid' whereas http_url_post() still uses FILE_CCSID() to set the ccsid of the response file.
I assume that you "forgot" to set 'global.file_ccsid' in procedure HTTP_SetFileCCSID() as you do it in HTTP_SetCCSIDs() for the other ccsids. As far as I understand your coding, you want to set keep the new 'global' values in sync with the old variables.
See:
* HTTP_SetCCSIDs() (sets global.net_ccsid and global.local_ccsid)
* http_setOption() (calls HTTP_SetCCSIDs() and HTTP_SetFileCCSID())
Problem report #2:
I faced a problem with the CCSID of encoded of URL parameters, when the remote and local POST CCSID matches the remote POST CCSID. In this case the URL parameters are not translated to the CCSID of the protocol data before they are encoded.
The problem seems to be the 'binaryData' switch of module CCSIDR4. That switch is set to *ON in HTTP_SetCCSIDs() when 'pePostRem' equals 'pePostLoc':
c eval BinaryData = *off
c if pePostRem = pePostLoc
c eval BinaryData = *on
c endif
Later on http_url_encoder_addvar_long() calls http_xlatedyn() to translate the URL parameter to the remote CCSID. The problem is that http_xlatedyn() does not translate the input data when 'binaryData' is set to *ON.
From what I understand, http_xlatedyn() is primarily used for translating POST data and not protocol data. Could that be the problem?
-- _______________________________________________ Ftpapi mailing list Ftpapi@xxxxxxxxxxxxxxxxxxxxxx http://scottklement.com/mailman/listinfo/ftpapi