Re: How about source PFs? (was: Is there an easy way to identify all the save files on a system?)

On 18-Feb-2015 12:14 -0600, Dan wrote:

On Tue, Feb 17, 2015 at 4:41 PM,<rob@xxxxxxxxx> wrote:

I'm rather fond of this simple query:

SELECT SYSTEM_TABLE_SCHEMA, SYSTEM_TABLE_NAME
, SYSTEM_TABLE_MEMBER, SOURCE_TYPE
FROM qsys2.syspartitionstat
WHERE source_type is not null
and system_table_schema='ROB'

<<SNIP>> I would, in fact, prefer a VIEW for which I can get a list
of every source member on the system. (I don't care about anything in
QTEMP.) If such a VIEW also provides a last modification timestamp,
all the better.

qsys2.syspartitionstat and qsys2.syspstat appear to be mirrors of each
other.

The former qualified name shows the SQL long-name for the object, and the latter qualified name refers to the _same database *FILE object_, but shows the system\short-name for that object.

For some unknown reason the KnowledgeCenter docs still have not been updated to include the short-name [to enable searching\locating docs with that name as search token]; the token appears neither within the VIEW layout page nor in the list of catalog VIEWs which is the parent topic\page of that VIEW layout, but the layout is here:
<www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/db2/rbafzcatsyspstat.htm>

Neither have the SOURCE_TYPE column defined as Rob suggested. We are
on v7r1. If there is a specific TR and/or PTF involved, please let
me know how to identify such.

IIRC the program QSQSYSIBM delivers the updates to the various catalog-like information; not sure if that program detects a down-level object or if a PTF-exit-program does for which a DROP is issued to enable the QSQSYSIBM to CREATE the updated object.

There is also a program QSQIBMCHK that may assist in validating, if not just existence, hopefully the condition of a down-level definition.

The IBM i 7.1 docs simply show that and some other fields with change flags; the only logical inference is that the change is *since* IBM i 6.1 and that all levels of v7r1 should have support. However, they\IBM have been poor at giving accurate indications there, and had made a statement that Technology Refresh (TR) information would be available on the DeveloperWorks site; no luck searching that column name there :-(

Being too lazy to try to figure out proactively if\when the installed code-level matches the existing object or if the code-level stores the new\updated definitions, I would just ask the code to create whatever is coded; I would just to delete [DROP VIEW ... CASCADE] the existing SYSPSTAT and call the program that re-creates the VIEW [ensuring first to set my job CCSID to match the non-65535 system-value or the otherwise most commonly used non-*HEX CCSID].

On 17-Feb-2015 15:14 -0600, CRPence wrote:

"If /member/ information is desired, the SYSPSTAT
[partition status] [or perhaps the table function used to implement
that] VIEW may be preferable."

Can you explain the "table function used to implement that" part of
the statement?

The VIEW named SYSPSTAT [aka SYSPARTITIONSTAT] is defined with a table-reference invoking the UDTF QSYS2.PARTITION_STATISTICS at least according to someone who has access to the VIEW_DEFINITION [from SYSVIEWS] or that same information from Display File Description (DSPFD) of the SYSPSTAT file. <http://archive.midrange.com/midrange-l/201309/msg00989.html>

Either the existing VIEW SYSPSTAT could be referenced, or a user-defined VIEW created with CREATE VIEW could be defined similarly to invoke that same UDTF to get the information\derived-table that is returned. The definition of that UDTF [what field names are returned] should be in the SYSFUNCS and SYSROUTINE [aka SYSROUTINES] files.