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



So, that's how it works in my solution:

- make a BLOB HTTP call
- exec sql
select cast(responseMsg as blob(2G))
, cast(responseHttpHeader as clob(1G))
into :responseMsgBin:http.iResHM
, :http.responseHeader:http.iResHH
from table(systools.HTTPBLOBVERBOSE(
URL => trim(:http.url),
HTTPMETHOD => trim(:http.method), // GET with query
parameters
HTTPHEADER => cast(trim(:http.header) as clob(10K)),
REQUESTMSG => NULL
)
) as httpRequest
;
- receiving variable is set according to HTTP call
- dcl-s responseMsgBin sqltype(BLOB: 2000000);
- use the specific SQL function
- exec sql
call QSYS2.IFS_WRITE_BINARY( // write UTF-8 file on IFS
PATH_NAME => trim(:fileFullPathName), // full path
LINE => :responseMsgBin, // received data (PDF) to
write
FILE_CCSID => 1208, // UTF-8
OVERWRITE => 'REPLACE', // replace if exists
END_OF_LINE => 'NONE' // don't need this
)
;


Done!

Il giorno lun 23 ago 2021 alle ore 17:48 Maria Lucia Stoppa <
mlstoppa@xxxxxxxxx> ha scritto:

Hi ,

@Tim: You are right: I have to save PDFs and I have just realized I was
using the wrong function (CLOB instead of BLOB). I made some tries with the
HTTPBLOBVERBOSE function but still have troubles with the CCSID of the
file, which finally is not readable.

I thought all the variables involved should be BLOB of the same size, but
probably I messed around too much. I am going to start again.

@Birgitta: I have already tried a couple of your suggestions (overwriting
an existing UTF-8 file and using IFS_WRITE_UTF8), but I will try them
again to find the one which works in my case.

Keep on trying
Thank you.



Il giorno lun 23 ago 2021 alle ore 17:28 Tim Fathers <tim@xxxxxxxxxxxxx>
ha scritto:

It looks like you're writing a PDF which would be binary, but in any
case, I would use a BLOB_FILE if you don't want the CCSIDs to be messed
around with then set the CCSID of the file afterwards to whatever it should
be using CHGOBJ. You will have to wrap the assignment of the BLOB with a
cast like this:

exec sql set :ifsPdfFile = blob(trim(:pdfDataFinal));

Tim.

________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of
Maria Lucia Stoppa <mlstoppa@xxxxxxxxx>
Sent: 23 August 2021 13:59
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: How does SQL determine the CCSID when creating a file on IFS
using CLOB_FILE SQL variable type?

Hi all,

Hope your holidays are going superbly!

Meanwhile, I am unsuccessfully trying to write a UTF-8 file on the IFS.
That's what I have done:

- the job is running with CCSID(280) inherited from QCCSID
- the HTTPCLOBVERBOSE SQL function returns UTF-8 data (which I want to
save) into a CCSID(1208) variable:
- dcl-ds http inz; // http call
...
responseMsg sqltype(CLOB: 2000000) inz ccdid(1208);
// http response utf-8 message
...
end-ds;
- this is the definition of a temporary variable
- dcl-s pdfDataFinal like(http.responseMsg); // same dimension
as http body
response
- this is the definition of the IFS destination
- dcl-s ifsPdfFile sqltype(CLOB_FILE) ccsid(*utf8); // I tried 1208
as well
- this is how I create the file
- pdfDataFinal = %trim(http.responseMsg);
// some stuff here
ifsPdfFile_NAME = %trim(fileFullPathName); // file name
ifsPdfFile_NL = %len(%trim(ifsPdfFile_NAME)); // name length
ifsPdfFile_FO = SQFOVR;
// SQFOVR= override, SQFCRT=create, SQFAPP=append, SQFRD=read-on
- so far so good, then I create the file:
- exec sql set :ifsPdfFile = trim(:pdfDataFinal);
- and the file in IFS is CCSID(280), no matter what! The receiving
folder is coded 1208, but the newly created file in the folder is 280
(seen
from WRKLNK).

Looking at the compilation spool file I looked at the variable definition:
227 //*DCL-S IFSPDFFILE SQLTYPE(CLOB_FILE) CCSID(*UTF8); // CCSID UTF-8

228 DCL-DS IFSPDFFILE;
//SQL
229 IFSPDFFILE_NL UNS(10);
//SQL
230 IFSPDFFILE_DL UNS(10);
//SQL
231 IFSPDFFILE_FO UNS(10);
//SQL
232 IFSPDFFILE_NAME CHAR(255) CCSID(1208);
//SQL
233 END-DS IFSPDFFILE;
//SQL

It seems to me that only the file name has the CCSID UTF-8 set, not the
content, though the data part of the variable is not explicit.

I tried changing the CCSID of the running job to 1208, but it revealed
impossible, but I couldn't find any other documentation.

Does any of you know how to do this?

Thank you very much
Kind regards
Lucia

--

Maria Lucia Stoppa
mlstoppa@xxxxxxxxx
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com



--

Maria Lucia Stoppa
mlstoppa@xxxxxxxxx




As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.