Re: WDSC CHGPF / CRTPF on existing file not replacing object

wdsci-l-bounces@xxxxxxxxxxxx wrote on 09/21/2011 01:00:03 PM:

----- Message from "Buzz Fenner" <bfenner@xxxxxxxxxxxxxxxx> on Wed,
21 Sep 2011 10:03:50 -0500 -----

To:

<wdsci-l@xxxxxxxxxxxx>

Subject:

Re: [WDSCI-L] WDSC CHGPF / CRTPF on existing file not replacing object

Michael Quigley wrote:

Paul, Bryce, Mark, et al,

It's not a matter of WDSC. If you submit the CHGPF to batch on the

green

screen, the message is not displayed nor handled. We opened a PMR

about

it years ago, but it never really got anywhere. If I recall correctly

the

response was basically "Working as designed." I've always thought
"working as designed" is a pretty lame answer, but I understand the
challenge--how do you ask whether to continue the CHGPF from a batch
environment? or more generically, a non-interactive environment such as

WDSC. Sending a message to QSYSOPR would wreak havoc on automated

build

tools. Anyway, the problem arises because you're either changing a

field

to an incompatible type, deleting a field, etc. As pointed out, the
initial CRTPF in QTEMP succeeds, but the command fails.

Michael Quigley
Computer Services
The Way International
www.TheWay.org
419 753-1222

I've also been pretty annoyed by IBM's answer (after confronting this

year's

ago).

However, within SEU, one is offered the chance to "replace object" which
allows the bypass of the confirm prompt via the session default

settings.

This is our shop standard; we assume that if you're at a point to make a
file change that impacts the record format, you don't give a rip about

the

existing data.

I just wish there was a way within WDSC/RDP preferences to effect the

same

sort of behavior. Wishful thinking I guess...

Buzz

I have to point out that there is no REPLACE(*YES) option on either the
CHGPF or CRTPF commands. PDM does offer you the chance to delete the
existing object, but that will fail if there are logicals over it. You
also have to write something to copy the data somewhere and then copy it
back or you will loose everything. Just to be clear, you can set the PDM
option for 'Replace object' to 'Y' and then it doesn't ask if you want to
delete an existing object. It simply deletes the object and proceeds to
generate a new empty object. That can be a real bummer if you've got data
you would have liked to keep. If you have logical files over the
physical, it simply will reply 'Cannot delete file or member of file...'
whether you've got 'Replace object' set to 'Y' or have said, yes when
prompted to delete the existing object.

You can request a feature enhancement, but honestly I don't expect IBM to
do anything about this. New development has been halted on DDS.
Everything is geared toward SQL-DDL. (Don't get me started on the poor
support of SQL in RSE.) You can perform an ALTER TABLE to your heart's
content. I don't recall ever having a problem with data loss not allowing
the alter table to complete. But SQL-DDL is a different mind-set. We've
been very slow to adopt it in our shop because there's nothing mandated as
to source format. So you can end up with a real bag of worms. Also, how
do you retain the source from a table which was originally generated by a
CREATE TABLE statement and then gone through several iterations of ALTER
TABLE? I personally have settled on doing a retrieve of the SQL source
after the alterations and saving that as my file definition in our
production source. I'm waiting to see if our System Administrator will
concur.

Michael Quigley
Computer Services
The Way International
www.TheWay.org
419 753-1222