Re: Level check using CREATE TABLE AS (SELECT

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Ah! Interesting idea. So I tried the simple case of QIWS/QCUSTCDT - the 
created table has a different format level ID, even when I specify the 
RCDFMT CUSREC clause. And if I make the name of the created file be 
CUSREC, it is also different from QCUSTCDT - and it is the SAME as when 
I use the RCDFMT clause.

I must be missing something. Another reply might have the answer.

Thanks
Vern

On 3/1/2013 11:31 AM, Crispin wrote:
> Vern,
>
> Different record format name...
>
> Crispin.
>
> -----Original Message-----
> From: Vernon Hamberg
> Sent: Friday, March 01, 2013 12:23 PM
> To: Midrange Systems Technical Discussion
> Subject: Level check using CREATE TABLE AS (SELECT
>
> I have looked around some, to find a solution. We have a process that is
> creating a duplicate of a table with selected columns into QTEMP. The
> table has a couple timestamps, otherwise it is all ZONED and ALPHA.
>
> One of the timestamps is a ROW CHANGE TIMESTAMP.
>
> The format level ID is not the same as the table used in the SELECT.
> Both objects are SQL tables, so it's not a matter of one is an SQL
> object and the other is not.
>
> Now to have a simple example, I tried it with QIWS/QCUSTCDT, and the
> result is the same.
>
>        create table qtemp/mytest as (SELECT * FROM qiws/qcustcdt) with no
> data
>
> Fmt lvl ID for QCUSTCDT is 3B84438D4C428
>
> Fmt lvl ID for MYTEST is 449C8BB02A248
>
> At this time we are doing a single-record CPYF, then some overrides,
> then an INSERT with OVERRIDING SYSTEM VALUE clause.
>
> Is this just the way it is, or is there a PTF to take care of this? I do
> not yet have access to PTF info here. We ARE at 7.1 of the OS.
>
> Thx
> Vern