Re: fields in a PF

A DDS PF would have to become a SQL TABLE, henceforth maintained with DDL instead of DDS. Thus no matter the intent of the question [which I am not sure I understand], the SQL DDL to create the TABLE with the desired [effectively the same as the DDS] attributes is effectively a requirement.

I had [¿incorrectly?] recalled that the ALTER TABLE request would cause the DDS PF to /become/ an SQL TABLE because of the ALTER [much like CHGPF SRCFILE() makes a SQL TABLE a DDS PF]; i.e. having effectively done a CREATE TABLE for the new database *FILE object, using the source obtained from the "retrieved SQL DDL" of the existing PF. However in a test on v5r3, the given ALTER TABLE [issued instead, against a DDS PF] was actually prevented per message CPF3230 "Data type for field I not valid" suggesting that "an identity column ... is only valid for SQL Tables..." :-(

If that implementation [which prevents the ALTER] has not changed to allow implicit conversion to a SQL TABLE [at your release], then the conversion from DDS PF to SQL TABLE would be required prior to the ALTER; i.e. two data copies required :-( Depending on the current DDS physical file and data [amount and NULL values], that copy could be very fast and simple; should be possible to accomplish the data copy with a save [to offline (tape) media] and a restore, if an online copy is not possible.

Regards, Chuck

On 14-Feb-2012 13:26 , fbocch2595@xxxxxxx wrote:

the SQL statements don't change DDS in any way...right?

CRPence on Tue, Feb 14, 2012 3:34 pm wrote:

On 14-Feb-2012 12:13 , fbocch2595@xxxxxxx wrote:

if I add a new field to a PF, is there a way the system can assign a
unique value to the new field without updating the field within the
program code? I've been told it can so I figured if anyone would
know how it would be you folks.

If an SQL TABLE is OK, then review this scenario:

<<SNIP>>
/* action: have database assign a unique value to the */
/* new\added column for all existing rows */
alter table id
add column i int not null generated always as identity
( start with 0 increment by 1 cycle)
add constraint id_i_pk primary key (i)
; -- ALTER completed for table ID in LIB
<<SNIP>>