Right, 254-263 is the JOB USER attribute. You want Current User...
D CURR_USER 358 367 * Current user
D * profile
-Eric DeLong
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James Lampert
Sent: Thursday, September 06, 2012 1:34 PM
To: Midrange Systems Technical Discussion
Subject: PROBLEM, Re: Almost a year and a half ago, I did some work with SQL UDFs.
Oh, boy, I just discovered some trouble.
As it turns out, I still have a censored view from my previous experiments.
The censorship, based on current signed-on user (as derived from the PGSDS)
D SDS
D LIB 81 90
D DUSER 254 263
works perfectly if I open the view with QuestView, or if I open the view
with STRSQL.
But if I look at the view from Squirrel SQL, through a JDBC connection,
the censorship doesn't work: I see records I'm not supposed to.
I see a QZDASOINIT job with these attributes (I've censored references
to my own user profile):
Display Job Status Attributes
Job: QZDASOINIT User: QUSER Number: 031575
Status of job . . . . . . . . . . . . . . . : ACTIVE
Current user profile . . . . . . . . . . . : <my-user-profile>
Job user identity . . . . . . . . . . . . . : <my-user-profile>
Set by . . . . . . . . . . . . . . . . . : *DEFAULT
I get the feeling that the PGSDS of my service program is returning
QUSER instead of my own user profile (with which I established the JDBC
connection).
How do I get around that, so the censorship function acts on the correct
user profile?
And I suppose this kills DETERMINISTIC, since the JDBC runs in a
prestart job. Or is there a way that the call to the UDF
WHERE CENSORACCT(U01430, U01429) = 'P'
in the view definition itself can pass (as somebody else suggested) the
user ID?
(And note, U01430 and U01429 are not user profile names; they're numbers
associated with user profiles).
--
JHHL
midrange.com
