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



If I'm following this correctly, which is one very big if, then given that
1252 is Windows Latin 1 and 1208 is UTF8 I would expect any conversion to
1252 to really toast any DBCS data found in the original file.

On Wed, May 11, 2011 at 5:56 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On Wed 05-May-2011 15:09 , sjl wrote:
When I run the same CPYTOIMPF command using as the destination a
folder in the IFS rather than a Windows folder via QNTC, it creates a
stream file in the IFS folder with CCSID(1208). When I run the
command a second time in order to append the same data to the
existing stream file, the appended data appears to be correct, which
makes sense since both the PF and the STMF are CCSID(1208).

So what about when STMFCODPAG(1252) is used on both requests instead
of the originally coded STMFCODPAG(*STMF) while exporting to a file on
the /QNTC as alluded could be attempted for a possible resolution?

Just a SWAG [without knowing about 1208\1252 or the actual code
points in the problematic source and target] that the origin for the
problem goes something like this:

cl> export from a field with ccsid(1208) to stmfcodpag(*stmf)
qcpexp> target file not found
qcpexp> if fromccsid(ascii_ccsid) then crtstmf(ccsid=fromccsid)
stmfapi> if targetfolder=/QNTC then ccsid=a_supported_ccsid
stmfapi> diagnose requested ccsid was not used
qcpexp> Openstmf(ccsid=binary) fine since tgtccsid=fromccsid
stmfapi> opened treated as binary vs text
qcpexp> file was created with no errors; warning goes unnoticed
qcpexp> gen each output record w/out xlate, both are ccsid1208

cl> export from a field with ccsid(1208) to stmfcodpag(*stmf)
qcpexp> target file exists, and stmfccsid=1252
qcpexp> Openstmf(ccsid=binary) regardless tgtccsid<>fromccsid
stmfapi> opened treated as binary vs text
qcpexp> file was opened with no errors
qcpexp> gen each output record w/ xlate ccsid1208->ccsid1252

Using STMFCODPAG(1252) instead of STMCODPAG(*STMF) [in both requests]
would seem probable to effect resolution [or circumvention] such that
the QCPexport should understand that the intention in both cases will be
to translate the data from the ccsid1208 to ccsid1252.?

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.