Re: CPYFRMIMPF and Unicode - UTF-16 in particular

On 03 Mar 2013 15:58, Vernon Hamberg wrote:

I'm considering using CPY - not CPYFRMIMPF - to copy the STMF
into a user space - haven't succeeded so far, maybe due to the
things you describe here.

As I had noted, the stream-file functions try really hard to not let you get non-EBCDIC data into the user space. Most invocations will fail with a complaint about the CCSID of the target "file"; i.e. the target as *USRSPC can not have a CCSID set "to match the CCSID of the source file" [source as in source\target, not source PF] according to CPFA098.

Failing that, I'll use the IFS APIs and be done with it. Once in a
variable in RPG (possibly based on a pointer to the user space), I
can figure out (guess) which encoding it is in. Then run that
transform API, which looks very easy to use.

I'm considering some kind of requirement that would let us use the
FROMCCSID to affect the FROMSTMF.

And if you could convince somebody to change the FROMCCSID to apply to the FROMSTMF, then you could import directly from the user space after the data has been transformed to UTF-16BE. But of course a limit of 16MB would be rather limiting :-(

I see that CPY has a FROMOBJ parameter, and FROMCCSID is used on
that for *TEXT. I think I really want *BINARY.

Will see if that works soon enough, I think.

On v5r3 I was able to trick\convince the CPY feature into copying the ASCII data into the User Space using the following script:

chgjob ccsid(*hex)
cpy obj(utf16) toobj('/qsys.lib/mylib.lib/space.usrspc') fromccsid(*JOBCCSID) toccsid(*JOBCCSID) dtafmt(*binary) replace(*YES)
/* dtafmt(*text) seemed to effect the same */

Personally I can not understand why, if the format is *binary* why the feature even cares about the CCSID of either source or target.? I wonder if the effect may be an /accident/ versus the intended function of that CPY invocation.?