× 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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.