Link to home
Start Free TrialLog in
Avatar of Theo Kouwenhoven
Theo KouwenhovenFlag for Netherlands

asked on

CHGPF vs CRTPF

Hi fellows,

can someone tell me the diference between the CHGPF and the CRTPF, yes I know the data will stay in the file, the LF's wil stay there, the security is the same, the triggers are still there.

But what is happening during the CHGPF???

Thanks a lot
Avatar of Member_2_276102
Member_2_276102

murphey2:

I've never looked at the details, but I wrote my own CHGPF way back in OS/400 V2R2, so I might guess.

Start with CRTDUPOBJ into QTEMP or perhaps QRPLOBJ for the PF with DATA(*YES). Then CRTDUPOBJ the various LFs into the same library. You now have a basic copy the file, the data and the logical views.

Now CRTPF into the original library replacing the original physical file. Then do a CPYF temp back to original with FMTOPT(*MAP *DROP). This reloads the data into the new file defintion. Then CRTDUPOBJ the LFs from temp back to the original library. Finally, delete all the temporary stuff.

There are a bunch of problems that must be overcome to make this work with all authorities and triggers and constraints and SQL views, etc.; but that kind of stuff is easy for IBM. With various APIs to retrieve all the info into user spaces or memory beforehand, everything can be recreated.

This isn't intended to say that IBM's command does it this way. It only gives a conceptual view of the kinds of things that can be done. I have a RGZDBRPFM command on my old web site ( http://zap.to/tl400 ) that has a few samples of what can be done to speed the process of rebuilding access paths if the file is large with many LFs that don't share access paths. My command uses Data Base Relations to cut the the re-org time on very large files. I suppose I ought to get back out there and modernize it, but it still works for most cases, so...

Tom
Avatar of Theo Kouwenhoven

ASKER

Yeah Yeah, I know,

I already have my own Zupdpd, and that is copying, creating, rebuilding, retrigerring and granting, but that was not the question,
I discovered the CHGPF just a couple of weeks ago, and I was wondering if IBM was as smart as we are :), or that they have an other way to add a column to the file.

SO ????



Good question... there are indeed a couple apparent oddities with CHGPF. Since IBM has direct access to any system state/system domain function, they can pretty much do whatever they choose regardless of what they let us do (without breaking security).

But, it's the same question that can be asked about all kinds of things -- e.g., IBM can mess around with program-associated spaces for ILE programs while we can only do so with them for OPM programs that have been compiled through the trusted translator (i.e., RPG or COBOL but not CL).

If IBM can directly manipulate object descriptions -- which they obviously can because they create them -- then there's nothing to stop them from rewriting the file/field descriptions directly and then simply moving bytes between data spaces adjusting for fields as needed and associating the new space with the updated object description.

Without major disassembly of CHGPF, I don't see how we can know. We could make some educated guesses based on what we see. I've seen one or two comments here about it.

Tom


Hi Tom,

Yes, that's what I was thinking, If I look to the speed of a CHGPF and to the speed of my own program, I have the feeling that CHGPF is faster (maybe just becaus it is using C instead of CL....)

Thanks for your reaction, I will leave the question open for a while, I'm almost sure that Dave will add some comment to this.
Hi
A very interesting question that I have been looking into.
I have found some very dangerous consequences of using CHGPF and will post results in the next few days.

Dave
ASKER CERTIFIED SOLUTION
Avatar of daveslater
daveslater
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Dave,

I already thought That this was a typical problem/question for you... :)

You mentioned ".....not too bad because the original data is still available."
do you mean when you change the field back from 9 to 10 pos, the last position must be available again????

Hi

You mentioned ".....not too bad because the original data is still available."
Hi that is right. but all of the other data in the file is available via the physical (except for the last byte of the altered field) and the logical file can be deleted.

But for a keyed physical I am not sure what will happen - and did not dare to experiment too much.

The command is designed to be used by programmers and I guess that you need to be carful.

Dave
Wow this is more then I expected, but when I look to your total story, the conclution is:

As long as-
- we don't make fields shorter,
- we don't mess around with indexes
it's quite save to use it.

most of the time I will just use it to add fields to a file. So no problem ?!?!?!?!




The more answers of this level I read, the more I be aware that I don't know very much about the AS/400 that's a bad score after 18 years AS/400 experience  ;-)


Hi
it is one of those things you take it on trust that it works, and for 99.999% of the time it will.
Now that we are aware of some limitiations we can make sure our system remain safe - and that has to be good news.

Again indexes are fine it is only unique indexs that are bad news.

Dave
Hi again
>>>The more answers of this level I read, the more I be aware that I don't know very much about the AS/400 that's a bad score after 18 years AS/400 experience  <<

It is not that we don't know much - it's just that the iSeries/AS400 is so vast and so poweful that our accumulated knowledge is probable about 20% of what the beast is capable of.

If IBM made the details more available I am sure that no other computer on the planet would come close. Come on Big Blue you have the best system out there - let the world know and let us know the full potential so we can develop world beating applications.

With ILE we now have the capacity to develop flexible, robust, highly scalable applications at great speed - but no one is doing it.

A slightly bemused Dave
PS
it kept me out of the lounge for a few days **grin**
Yeah,

The machine is good (the best) the DB fast, the posibilities are endles...... but my boss perfers to sell websphere, and don't put any power in AS/400 customers, market or developement.... only networking en e-Junk.

So I'm afraid that the 400 had his best (longest) time......
Hi
I have just found out some more info.
The accesspath is re-built asynchronously instead of synchronously which is why it is quick and can not check for duplicates.

Dave