RE: Security question

Touché', Chuck.

The KISS principle always trumps "elegance". I have no problem being called
a luddite.

:-)

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Thursday, November 19, 2015 12:29 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Security question

On 19-Nov-2015 10:53 -0600, rob wrote:

All nice teases but I suspect Paul is working on some ancient system
that "if it isn't broke, why fix it?" and he will be relegated to
RTVUSRPRF.

And why not use Retrieve User Profile [or Retrieve Object Description
(RTVOBJD)] irrespective of the modernity of the system\version? The
request from the OP, almost surely is not best served by any of the
previously mentioned UDTFs or any VIEW implemented on such a UDTF.?

Just how and why, on a system with perhaps up to many thousands of
users, a request that would gather the information about *all users*,
could satisfactorily be considered a /fast/ means to obtain just one
datum of just one specific user; processing that would seem to mimic
quite closely [even if the UDTF is faster than] the behavior of the
Display User Profile (DSPUSRPRF) for the information of TYPE(*BASIC)
that the OP seemed intent on avoiding?

I just do not understand the seemingly overwhelming amorousness being
so fervently and so often expressed towards the various DB2 /services/
features that perform vastly more work than necessary; what would then
get pared down to just one row by selection implying that the data would
be reprocessed [i.e. scanned after generated] and would effect the
overwhelming amount of data remaining /purposefully unreferenced/ as
actual output to the program.

By all means use those services for the convenience and with purpose,
but please do also exert _some effort_ in contemplation of the actual
amount of work they entail, before thoughtlessly deferring to those
services. From the OP, there seems little justification, in fact quite
the opposite, in using those services over using the much simpler
RTVUSRPRF [or RTVOBJD].