The job CCSID in the given scenario has no affect, because all of the
CCSID tagging for the data is at the column level.
The /correct/ way to change the CCSID of fields in a file is CHGPF
SRCFILE() or ALTER TABLE. Regardless, without any attempt to comment on
the claim that there is a difference between batch and interactive...
The copy of a file that is created by the CPYF CRTFILE(*YES) will
[like CRTDUPOBJ,] share the record format of the file that was copied.
If the requested CCSID change does not actually change a /column CCSID/
of a column with a character data type, then the format is still shared;
only the /text fields/ of the various composite pieces of the file are
updated to the given CCSID. So if the requested CCSID change does not
affect any columns, then a change to one copy of the file changes them both.
DSPDBR RCDFMT(*ALL) will show the list of files sharing the format of
a physical file named on that request. The first file named in the list
of files, is the current /owner/ of the shared record format; if only
that one file is named, the format is not shared.
If there is an actual column CCSID that changes, then the message
CPD3238 should be issued to inform of the result, that a new format had
to be created for the changed file [because the changed record format
for the changed file is no longer compatible with the other copy].
Please note that the CHGPF CCSID(value) invocation was only enabled
and intended for the transition from when no CCSID was implemented for
database files, to when there was. Its intent was merely to enable
establishing the appropriate CCSID where the automatic establishment of
a CCSID was not the desired value. Be aware that it is really a flawed
function, outside that use, because it changes the CCSID of all of the
/text fields/ of the file; colhdg, text(), rcdfmt text, comments, field
text, labels, member text. Unfortunately the CHGPF CCSID() function was
/enhanced/ by its removal of some restrictions, but without regard to
its original design limit which makes its function [of changing the text
CCSID] an effective defect; that issue was closed as a "permanent
restriction" long ago, but I can not find the APAR. There was another
APAR that dealt with flaws for files with UCS2 & UTF fields, but I do
not recall what was done; again I can not find the APAR.
Some history about the enhancement, and a reference to column heading
which is one of the /text fields/ that is tagged; the QDBRTVFD will show
a CCSID for each /text field/ that makes up a file:
http://www.redbooks.ibm.com/redbooks/pdfs/sg242154.pdf
"2.4.3 Changing CCSIDs of Physical Files"
"2.4 Multilingual and Multi-System Database Support"
A KB article that touches on the subject:
http://www-912.ibm.com/s_dir/slkbase.NSF/643d2723f2907f0b8625661300765a2a/262197699cc75e00862565c2007cef09?OpenDocument
"IBM Software Technical Document number 8480206" Q5 & Q6
If CHGPF SRCFILE() or ALTER TABLE is not used, then creating the PF
from DDS or DDL, into which the copy of data is then performed, is the
best option as suggested in the response to Q6 in the above document.
Unless the DDS source has an explicit request for format sharing, doing
the create prevents the CHGPF CCSID() from having to deal with any
record format sharing, and thus would circumvent the described issue.
Regards, Chuck
David Gibbs wrote:
Ok, I've got a weird problem with CCSID's here. I'm betting the answer
is obvious, but I'm missing it.
Got a program that's trying to change the CCSID on a bunch of files.
It copies the data in the files original CCSID to a temporary library
(CPYF with CRTFILE(*YES)) ... then does a CHGPF on the original, and
then copies the data back from the copy using CPYF with MBROPT(*REPLACE)
and FMTOPT(*MAP) so the data is transcoded back to the new CCSID.
The problem we're encounter is: After we copy the original file to the
temporary library and then do the CHGPF ... both the original file AND
the copy have their CCSID's changed.
The job is running in an appropriate CCSID (5026 in this case). The
original file has a CCSID of 937 before the copy ... and the duplicated
file has that same CCSID before the CHGPF is run.
The logic is pretty darn simple ...
CPYF FROMFILE(ORIGLIB/ORIGFILE) TOFILE(QTEMP/ORIGFILE) CRTFILE(*YES)
CHGPF FILE(ORIGLIB/ORIGFILE) CCSID(5026)
CPYF FROMFILE(QTEMP/ORIGFILE) TOFILE(ORIGLIB/ORIGFILE)
MBROPT(*REPLACE) FMTOPT(*MAP)
(the ORIGLIB & ORIGFILE are both variables, but I know the values are
correct).
Oddly enough, if we run the steps by hand (in an interactive job), the
copy works perfectly. This problem only happens when we run the copy in
a batch job.
Any thoughts? I'm kind of stumped.
As I said, I'm sure it's something obvious ... I just can't see it.
midrange.com
