On 03 Mar 2013 15:58, Vernon Hamberg wrote:-snip-
I'm considering using CPY - not CPYFRMIMPF - to copy the STMFAs I had noted, the stream-file functions try really hard to not let
into a user space - haven't succeeded so far, maybe due to the
things you describe here.
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.
And if you could convince somebody to change the FROMCCSID to applyI believe I actually ran into that limit - I got a different message, CPFA0A2, Information passed to this operation was not valid. And the sample I was given was around 20 MB. So tricking CPY didn't work - it did with a shorter stream file.
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 :-(
On v5r3 I was able to trick\convince the CPY feature into copying the
ASCII data into the User Space using the following script:
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.?
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact