On 18-Oct-2016 09:13 -0500, David Gibbs wrote:
I'm a bit confused about the CPYTOIMPF command's STMFCCSID &
STMFCODPAG parameters.
The two parameters should be, essentially mutually exclusive [perhaps
not fully enforced; e.g. for *STMF default or explicitly specified],
with the former superseding the latter.
Can anyone point me to a concise explanation of what the they are
supposed to do?
With the specification of the older Stream File Code Page
(STMFCODPAG), and since, with the Stream File Coded Character Set
Identifier (STMFCCSID), the intent is to allow assigning with what CCSID
the new output file should be tagged; i.e. if the file already exists,
the specification is quite nearly ignored [if not instead, the cause for
an error being issued].
Here's the problem ... at one customer, when we run the CPYTOIMPF
command on a file with CCSID 937, with the STMFCCSID parameter set
to *PCASCII, we get EBCDIC in the resulting stream file.
The actual command string is typically best, to reveal more, and
further knowing any changed command defaults helps eliminate further
unknowns in review of the request. Also, for that feature, be sure to
use a *ALLOBJ user and review for and record any results of WRKDTAARA
QCP*; the list and data within any appearing on the list.
And often, implications such as that [i.e. we get EBCDIC], requires
actually determining how that conclusion was made; by what interface et
al. Easier just to provide actual hex data used as the input and the
hex data resultant as the output; the Dump (DMP) command for a STMF will
show the actual hex rather than other interfaces that might more easily
confuse -- i.e. Display File (DSPF) will translate the data to the job
CCSID, thus into an EBCDIC CCSID. Copy File (CPYF) using Output Format
(OUTFMT) of *HEX and To File (TOFILE) of *PRINT will do similar for a
database file member.
Perhaps the "resulting stream file" was a pre-existing file with an
EBCDIC CCSID? Note also: generally a CCSID is specific to the column
rather than to the file; e.g. some [var]char column(s) with the mixed
CCSID 937 was exported. The given scenario, for output/export to a new
STMF, presumably should have effected creation of a file having been
tagged with CCSID(950) as a "computed"/corresponding x4105 Multi-Byte
Character Set (MBCS) CCSID; and of course, that mixed EBCDIC data would
be expected to have been translated into that ASCII multi-byte data.
On the same customers system, with the same file, if we set the
STMFCODPAG parameter to *PCASCII, we get a ASCII text file.
What about the other parameter specifications on the Copy To Import
File (CPYTOIMPF); i.e. other than FROMFILE() and STMFCODPAG()? And
again, "get ASCII" is better described with methodology, but the DMP
request avoids having to try to explain [in words or scripted actions].
Any thoughts?
Eliminate the possibility of pre-existing files. And in any test,
review/record first what is the Coded Character Set ID presented on the
Display Attributes panel via the option 8=Attributes from Work With
Links (WRKLNK). Then, beware interfaces that might confuse the viewer
about what data is actually in the file; i.e. be sure to use an
interface that gives the hex values rather than trying to show
representational glyphs, such as DMP. Verify also what is in the From
File (FROMFILE) and that the data as code-points matches the CCSID tagging.
midrange.com
