Re: Copying from/to qntc performance

On 29-Jun-2015 11:25 -0600, Alan Cassidy wrote:

On 6/5/2015 2:34 PM, Scott Klement wrote:

<<SNIP>>
2) Why did you specify TOCCSID(*CALC) on your CPY command? I suspect
it's ignored because DTAFMT(*BINARY) is the default on the CPY
command. But to someone who doesn't know that, the TOCCSID(*CALC)
would seem like a curious thing to do. Translating save file data
between CCSIDs makes no sense.

Okay, what finally worked to do this to back it up was a CPYTOSTMF
as Scott Klement suggested from the save file, with the
DBFCCSID = 37 and the remote CCSID = 1252.
<<SNIP>>

FWiW: Similar to what Scott noted for the CPY command, specifying the CCSID values makes no sense on the Copy To Stream File (CPYTOSTMF) command invocation. Those explicit specifications seem to imply that the data would be corrupted by character translations, because only *BINARY copy is valid for save file data to maintain the integrity.

Like the older parameter Stream File Code Page (STMFCODPAG), the Stream File CCSID (STMFCCSID) parameter is _ignored_ when the From File Member Or Save File (FROMMBR) refers to a Device Save File (SAVF); as are the Database File CCSID (DBFCCSID), Data Conversion Options (CVTDTA) parameters, End Of Line Characters (ENDLINFMT), Conversion table (TBL). Probably better to have the command specification specify either the same explicit value on both of the STMFCCSID and DBFCCSID parameters, or omit them entirely; the combined specification alluded, i.e. DBFCCSID(37) STMFCCSID(1252), makes the command string appear [to a casual but somewhat informed observer] that the effects would be detrimental.