RE: Copying from/to qntc performance -- MIDRANGE-L

Chuck,

I agree that the CPYTOSTMF as both *BINARY and using CCSID values is counterintuitive.

But we couldn't make it work and kept getting a severity 40 CCSID error message until we used those values. My guess was/is that it is "just" an attribute that Is required for all stream files in the IFS, especially the QNTC. I am open to other ideas on that, but we had to make it "work" before we could get to run any test at all.

Larry,
I calculated about the same thing, about three hours speaking conservatively. I'm going to ask our main network guy about other traffic.

Bu I think we have to go through these steps till we have enough to claim that they have to spend some budget, or we solve this, whichever comes first.

I haven't been on the sys-admin side of support since almost the last century, whence our trial-and-error. There are only two midrange developers here including myself and he likes to keep the controls, fine with me. (Don't blame me!). But we just took shipment of the machine local to in-house from the application vendor, who took care of all this before.

Matt,
I'll check out Samba, thanks for the suggestion and your experience. I also welcome any other alternative ideas. (Other than manual courier, ey).

Thanks to all,
Alan

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, June 29, 2015 2:04 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.

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

--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------