Dan wrote:
Responses inline:
On Fri, Feb 19, 2010 at 6:59 PM, Scott Klement wrote:
The other thing I'd try if pre-creating the file didn't work
for some reason is to run CHGPF to change the CCSID to the
correct one after the transfer.
Tried that, got CPD322D:
"Explicitly specified CCSIDs or file restrictions present."
Don't know how "explicit" applies here, unless it's FTP
"under the covers".
When a database file is created for a client on GET or server for
a PUT [into /QSYS.LIB file system], the implementation is much like
having coded a CRTPF SRCFILE(QTEMP/CUSTOM) where the CUSTOM DDS
member has been generated or modified dynamically before each CRTPF
[yet without actually using the DDS /compiler/]. The dynamic
source updates would reset the field name, record format name, and
the function for the field set to CCSID(&CRTCCSIDorBESTFIT);
adjusting the data type as required, to match the chosen CCSID.
Thus the CPD322D would be RC1 to signify that the field(s) of the
file have had a CCSID explicitly set.
FWiW the diagnostic error msgCPD322D also says "or file
restrictions present". That would be the case for a file created
using CRTPF SRCFILE(*NONE) RCDLEN(#), with the RC4 [return code 4]
suggesting that the "file is a program described file" is the origin
for the restriction. Since each program must describe such a file
for its own use, a CCSID is not applicable, so the /restriction/ in
that case is that no CCSID can be set; i.e. the file is implicitly
always identified as having *HEX data with CCSID(65535) for all of
its [apparent] fields, such that any data conversion would be the
responsibility of the program rather than the program depending on
the database to effect any data\character conversions.
FWiW: Unlike *USER or *SYSVAL as noted in the KB article, I would
suggest specifying explicitly, whatever is appropriate to the data
being transported. That is, those special values could be a moving
target, since they may be changed. IMO an application should not be
at the whim of such a change; so if the user performing the FTP is
defined by an application and its CCSID() is established, or for any
user FTP GET\PUT requests where that user knows their CCSID() is
properly set, only then would the *USER would seem appropriate. IMO
most installations should probably CHGFTPA CRTCCSID(*USER) and
ensure all user profiles are set to their most desirable CCSID.
Note: The ability to change the CCSID of a database file was
really only ever intended to assign a file its intended CCSID from
when it never had a CCSID prior to v2r1m1, or change the CCSID that
was assigned by the system for such old files when what CCSID was
set was either an accident per incorrect system setup or simply an
undesirable choice for the installed primary language; e.g. 285
being specific versus 500 being more /international/. The only
other database files that should be changed using CHGPF CCSID(#) are
the occasional "source physical file" for when they were created
incorrectly originally, and all data I\O since then had been
performed under job CCSID(*HEX) & within a consistent language
environment matching the to-CCSID value; i.e. the CCSID tagging of
the SRCDTA column will be changed to the new value, but the data in
all rows of all members remains the same code point. IIRC, if the
CHGPF CCSID(#) is used for some reason, the best results will be
from issuing the request twice, where the first invocation is CHGPF
CCSID(*HEX). There is an unresolved APAR documenting that the CHGPF
CCSID(#) incorrectly changes the "text CCSIDs"; i.e. COMMENT ON,
LABEL ON, CHGPF TEXT() and CHGPFM TEXT() character string values
will also have their CCSID reset, irrespective of what data is
there, and that the CCSID for those text portions of the file,
member, and record format (fields) may already be correctly tagged
such that having the CCSID(#) changed to the new value may cause
problems for mis-tagged data.
<<SNIP>>
Regards, Chuck
midrange.com
