×
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.
On 25-Feb-2014 05:06 -0800, xtreme2009@xxxxxx wrote:
I wrote a CL program to run a few queries for the client, and
then use CPYTOIMPF command to transfer the output file to IFS shared
folder. The command used is as follows:
CPYTOIMPF FROMFILE(HS#LIBLB/EXPERIANF) +
TOSTMF('/CHLB/00100/PROD/BO/EXPERIAN/EXPERIANF.TXT') +
MBROPT(*REPLACE) FROMCCSID(*FILE) STMFCCSID(*STMF) +
STMFCODPAG(*STDASCII) RCDDLM(*CRLF) DTAFMT(*FIXED) +
STRDLM(*NONE) FLDDLM('') DATFMT(*USA) TIMFMT(*USA)
So I call the program and once it completes, I open the notepad from
shared folder pointing to the IFS (that's how the customer access the
file) the dates and few characters appears as junk. Any idea how to
fix this?
The CCSID attributes of the From-File (see DSPFFD HS#LIBLB/EXPERIANF)
or the From-File CCSID (FROMCCSID) specification are the likely origin
for the issue; i.e. the "appears as junk" is likely an effect of the
data reaching the destination as EBCDIC, and the Win application unable
to deal with anything but ASCII. The resolution for that is to do one of:
• /correct/ the CCSID tagging of the columns in the physical database
file being exported [the FROMFILE()] to indicate that character
translation is relevant\important
• use a logical VIEW to cast the data to an appropriate CCSID for
those specific columns that require the character translation; name that
VIEW instead of the physical file as the FROMFILE()
• insert an additional step after the export to translate the data to
ASCII; e.g. if the export changes to use a TOFILE(), then CPYTOSTMF can
be used to effect that conversion, but the next option is easier and
should have the same effect:
• if all columns are incorrectly CCSID(*HEX) [aka CCSID(65535)] then
using the FROMCCSID() specification to override how all of those columns
should be treated as character data requiring translation [rather than
treated as binary] may suffice
The most appropriate, but possibly the most difficult, is to correct
the From-File to have the proper column CCSIDs; i.e. the first listed in
the above. Depending on what defines the having "run a few queries" may
make the resolution easier or even more difficult; e.g. a /query/ might
be able to effect what the VIEW would effect, but established directly
in the physical file.
Some additional comments:
Choose either STMFCCSID *or* STMFCODPAG; the former replaces the
latter which is deprecated.
Having chosen DTAFMT(*FIXED) [and AFaIK this has not changed], the
parameters String Delimiter (STRDLM) and Field Delimiter (FLDDLM) being
solely related to having specified DTAFMT(*DLM), those specifications
are being ignored. I would not expect those specifications to have any
effect, unless a capability were added to specify a field definition
file on export.
midrange.com
