Re: CCSID 37 / 500 issues with FTP

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