Re: sql to obtain date shown in PDM for member (f14)

Sorry. Just seeing this thread or would have helped explain sooner.
I ran off so quickly once rob pointed out the partionstat table, which was exactly what I needed.

The reason for checking members will be clarified in my very first post. We have an old archaic solution that had all our tables that were created up to 2006 scrubbed for identified sensitive data.
My objective is to replace that old solution with a new dynamic solution but only need to worry about tables changed/created since 2006. See original post why we don’t want to refer to object last change date.
At the end of the day, this research project has evolved into a new method to allow us to scrub data and partitionstat is no longer even used. Only syscolumns will be and we are including all tables not just the “prior to 2006” ones as the old scrubbing process will be retired now.

Jay

Sent from my iPhone

On Oct 10, 2019, at 12:10 PM, Rob Berendt <rob@xxxxxxxxx> wrote:

I was wondering why checking the source.
If it was to find where sensitive data was, then I would look at the data tables instead of the source tables. This would help you find copies.
However if it was to find where the sensitive columns were defined (assuming you have source for all) so that you could change the definitions to encrypt them then looking at the source is a fine idea.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of John Yeung
Sent: Thursday, October 10, 2019 11:33 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: sql to obtain date shown in PDM for member (f14)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Thu, Oct 10, 2019 at 10:37 AM Rob Berendt <rob@xxxxxxxxx> wrote:

He was using syscolumns against the source PF's, not the actual tables.

Well, this line suggests otherwise:

and b.system_table_member = a.sys_tname

He's getting the table names from SYSCOLUMNS which match the source
member names from SYSPARTITIONSTAT. If you want to call that "using
syscolumns against the source PF's" well, then I guess he's guilty as
charged, but that was his whole objective in the first place.

Rob, you seem to enjoy being snotty-but-obliquely-helpful by pointing
out what you consider mistakes, or at least "suboptimal" solutions.
What surprises me is that you've now given two responses that aren't
even backhandedly helpful, yet you haven't bothered to mention that an
explicit JOIN clause is better than the "comma-where" style of
joining.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com