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
midrange.com
