How to set remote CCSID for sftp

[zukes1966]

Dear Scott,

For above case IBM support responded:

More than likely this system needs SI84164 - Remove UTF8 SETCCSID in libchttps://www.ibm.com/support/pages/ptf/SI84164
To go along with the PASE_DEFAULT_UTF8 'N' you would need this ptf to ensure new objects created in PASE use country/language settings and not just arbitrarily use CCSID 819.

I'll try setting

ibmpaseforienv PASE_DEFAULT_UTF8=N

but first we are going to install PTF.

Why I want keep 912 instead 1208?

1. Because the data in the *STMF files is saved using CCSID 912.
2. If I allowed CCSIDs other than 912, I would have to rewrite a very large number of applications.

This is the reason why we need backward compatibility

[john.sev99]

I agree with the previous comments from Scott. From what I can gather, sftp is being used to transfer the files to your system. As far as I'm aware, this only transfers data in binary format, so no conversion of data takes place. The data in your destination file will be identical to the data at the source. If the CCSID of the destination file is wrong causing the IBM i to misinterpret the data, why not just change the CCSID using CHGATR so it matches the data in the file?

[Scott Klement]

You aren't just changing the CCSID of the file. You are changing the CCSID of everything in PASE, purely to fix one file.

Just changing it with CHGATR or setccsid after the transfer will fix it for the one file. It does not require changing lots of other code.

[zukes1966]

IBM PTF was necessary for solving above problem: PTF SI84164.
After PTF instalation environment variable PASE_DEFAULT_UTF8=N start working

[zukes1966]

Scott,

Let's say you have 1000 different files, each with data CCSID 912. For each of them you have a separate application to import this data into DB2.
Let's say you want to introduce CHGATR for these 1000 applications. Changes, tests, risks.

Unfortunately, the FROMCCSID() switch for CPYFRMIMPF does not work if *STMF has a page other than 65535.

It's easier than modifying 1000 applications to save the data file on IFS with CCSID = 912. And this is possible thanks to the environment variable.

[zukes1966]

And this is possible using an environment variable PASE_DEFAULT_UTF8=N

[zukes1966]

AFTER implementing V7R5, we have another problem with the open *STMF API (32 and 64 bit same behavior).

For V7R3, using O_TEXTDATA and NOT specifying "codepage" in the open/open64 call resulted in the CCSID for the job being used for conversion. Now, depending on the CCSID *STMF, an exception (no access to the file) may be generated.

[Scott Klement]

AFTER implementing V7R5, we have another problem with the open *STMF API (32 and 64 bit same behavior).

For V7R3, using O_TEXTDATA and NOT specifying "codepage" in the open/open64 call resulted in the CCSID for the job being used for conversion. Now, depending on the CCSID *STMF, an exception (no access to the file) may be generated.

By that do you mean you are doing something like this?

fd = open(path: O_RDONLY + O_TEXTDATA);

If so, you should be getting an error for any file that has CCSID = 1208 (or another mixed encoding CCSID). This isn't new behavior in 7.5, it has worked that way all the way back to V5R2.

You see, prior to V5R2, the IFS did not support CCSIDs, it only supported code pages. Code pages don't support CCSID 1208 or any other mixed-encoding, because mixed encodings are made up of multiple code pages that you switch between... that's what a mixed encoding is. So you need full CCSID support for those, not just code page support. But, prior to V5R2, there was no CCSID support in the IFS.

When they added CCSID support, they provided the new O_CCSID flag for open(). If you don't specify the O_CCSID flag, it will continue to behave the old way and use code pages.

For V5R2 and newer, you should be coding it like this:

fd = open(path: O_RDONLY + O_TEXTDATA + O_CCSID: 0: 0);

O_CCSID tells it to use the CCSID support rather than code pages. The first 0 means "not creating the file, so no need for permission info" and the second 0 means "my program data is in CCSID 0" (0 is a special value for the job CCSID)

Again, this is not a new feature, it goes all the way back to V5R2. But you may not have needed it because you were using code page 912 (which is a single byte encoding, same as ccsid 912). You'll have to fix it in order to use 1208.