Re: Which of the SYSIBM tables/views show the row count for

Joe Pluta wrote:

Tom Liotta wrote:

...especially when it can be easily added (created) with a ADDPFCST command even if there is no key in the DDS.

Be careful here... you can't add a *PRIKEY over a file if a non-unique key already exists.

Agreed. I'd intended that my comment be fairly restricted in scope for a reasonably well-defined purpose. If a conflicting key exists in a different scenario, then the complexity rises significantly.

Actually, the process that I use pulls in a number of "utility" procs that provide automated protection. E.g., among other elements, database relations are retrieved and all related keys are examined to determine unique keys already existing in LFs. The databases in _this_ (emphasized again) case are known to have at least one appropriate unique key.

And it's also known that the PFs have no keys (AFAIK, due to the age of the databases.) This relates to Rob's long-standing comment about such non-keyed PFs out of historical reasons that are almost forgotten today.

The use of CPYF *UPDADD seems rare and I believe it's often because old PFs never get their descriptions updated for keyed access. While *UPDADD has only limited use cases from the start, it can make some maintenance tasks easier. It's just that I have a recurring situation that (1) is never gonna get approval for database redesign and (2) needs infrequent but periodic updates from a source external to the databases.

And doing the coding for the "fix" to _this_ problem was made far easier by ADD/RMVPFCST.

Tom Liotta