Re: View to create a PF?

On 23 Aug 2013 13:04, Hoteltravelfundotcom wrote:

<<SNIP>> if I am the creator of the view, then as long as I change
this [<ed> the CCSID setting] on my USRPRF, then it [<ed> the CCSID]
will be fine for all users of this view?

The CCSID of a column in a logical [VIEW] file is fixed\static. The column CCSID could have been established explicitly in the VIEW using the CAST() to specify whatever CCSID, or the column CCSID could have been adopted from the CCSID of the job in which the VIEW was created. In the latter case, care must be taken to ensure that the VIEW is re-created /properly/ [i.e. the CCSID() for the job previously set] to effect the desired CCSID after either a DROP VIEW or DLTF, or when using CREATE OR REPLACE to accomplish effectively the same.

While the column CCSID is described above as static, the potential exists for a change if either the underlying TABLE is altered and thus the VIEW is re-created, or the VIEW is restored. The restore is effectively a create, but moreso when restoring just the LF instead of restoring the LF in conjunction with all of its based-on PFs. In either case however [restore or ALTER], the CCSID used for the derived columns that are not assigned directly either from the CCSID of the physical column(s) or the CAST() [i.e. for the CCSID of literals or expressions that originally had come from the CCSID() of the job vs from explicit CAST] *should* be extracted from the stored query [the QDT; a part of the VIEW] rather than coming from the job performing the ALTER or the RSTOBJ in order to prevent the CCSID from being variable. Or restated, the CCSID() for the job doing the ALTER or RSTOBJ should not change the CCSID originally assigned to literals or other expressions for which the CCSID had not been established from the CCSID of the column(s) of the underlying TABLEs during CREATE VIEW.