RE: CRTPF question?

Tim Truax (truax@usaor.net) wrote:

>Why isn't there a keyword on the CRTPF CL command that will give you an
>option to reserve the files existing data and then *ADD the data back
>using the FMTOPT(*NOCHK) for you?

FMTOPT(*MAP *DROP) surely? FMTOPT(*NOCHK) will give bad results if the
record layout has changed, which is quite probable since you're
recreating the file.

>Is this a stupid question?  But the
>OS400 developers seemed to have thought of everything so I am suprised
>that you have to go thru several steps when changing a physical file
>(Change the DDS, CRTDUPOBJ the current file,

It's quicker just to rename the old file, or move it into another
library than to do a CRTDUPOBJ DATA(*YES).

>then CRTPF the new blank
>file, then CPYF the old data into it) Is there a good reason for these
>methodical steps?

I think the basic reason, Tim, is that it's more complex than probably
you realise. It might be possible to add a REPLACE parameter to the
CRTPF command, but it would need other parameters too, to specify what
would happen to the replaced data and the logical files. Would you
expect to see the replaced file along with its data and associated
logical files in retained QRPLOBJ? Would you want some kind of control
over the number and size of replaced files still on the system? What are
the implications of users still happily adding data to a file that's now
on borrowed time in QRPLOBJ?

Would you also have the logical files rebuilt automatically? How would
the command handle join logical files that are built over your replaced
physical and another physical? If you were going to recreate that
physical next you wouldn't want the logical rebuilt twice. You'd also
want options to omit the rebuild of any logical files that you were also
planning to recreate yourself. Would you want to have the *MAP and *DROP
options of the FMTOPT parameter specified explicitly to guard against
the possibility of inadvertent data loss, and how would you tidy up
afterwards if the copy stage failed?

Also these days, I suppose, you would want to have parameters to control
the recreation of any triggers and referential integrity associated with
the replaced file. The whole process could be extremely complex and
long-running. I'm not sure the complexities of the command and the scope
for error would be worth the trouble.

Assuming IBM could build a replace option successfully, I think it would
be almost more complex to get to grips with all the ramifications of the
various options than to use your own simple procedure, appropriate for
the file you are replacing. My usual method is to move the replaced
physical and associated logicals to another library, recreate the
physical with CRTPF, copy the data with FMTOPT(*MAP *DROP), recreate the
logicals using CRTDUPOBJ leaving out any I might be about to create with
CRTLF, delete the moved logicals, delete the removed physicals. However,
there may variations on this in different circumstances.

Dave Kahn - TCO, Tengiz, Kazakstan
=========

e-mail:  kahn@tengizchevroil.com    (until August 5th)
         dkahn@cix.compulink.co.uk  (from  August 6th)

Note new e-mail address in Kazakstan
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *