×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 23-Jun-2016 14:52 -0500, Stone, Joel wrote:
I have seen two methods:
1) Pass it into the pgm as a parm
2) Use the PSDS and force an error as described in
[http://www.itjungle.com/fhg/fhg050113-story02.html]
Is there a better, cleaner, more intuitive method?
Does "user-ID" have a "standard" definition [probably not, if not
found to be provided as part of the ANS language], or at least have a
specific definition? While I supposed if I read the article, I might be
able to infer, the term [expressed only in the Subject] from the OP
remains ambiguous; seems probable, that the "PSDS-User-profile" shown in
the article might give the /job-user/ obtained from the qualified job
name, whereas the presumed most likely as-desired value would be the
/current-user/ of the job.?
Passed as a parameter could be the best, if the caller already knows
to what user-ID value the called program should refer, given the calling
programs can not defeat any security intentions by having been allowed
to specify\pass that user-ID value via that parameter. If the only way
for the called program to know the intended value of user-ID [given that
value is not passed as a parameter] is to infer the value by something
contextual about the [how\when\who\etc. of the] invocation, then even
more likely passing the value as a parameter might better than being
/calculated/ by the called program. Specifically, if the called program
must know something about the environment to decide what is meant for
the user-ID, for example, calculable only by knowing the answer to
/who-called-me/, then in many [non-security\authority] routines, the
value should be passed as a parameter rather than calculated by the
called program, so as to avoid false inference and\or assumptions being
made in\by the called program.
The second option seems like a hack; something that might be
considered too /clever/ [aka obscure] to be generally appropriate [for
use in production code], at least without some good docs and a clear
separation into a procedure -- at which point, there would seem to be
little reason to instead just code something else more conspicuously
obvious such as:
Otherwise probably most simply that would be achieved by just
retrieving the desired value from an [effective] API that is documented
to retrieve whatever is the desired value for user-ID; the Retrieve User
Profile (RTVUSRPRF) and the Retrieve Job Attributes (RTVJOBA) both are
effective APIs [as CL commands with Return-Value (RTNVAL) parameters],
as would be referencing the SQL CURRENT USER or any similar SQL special
registers, and for example, the Retrieve Job Information (QUSRJOBI) API
and Retrieve Thread Attribute (QWTRTVTA) API both are explicitly noted
to be [callable] APIs. Note, the definition for "the user-ID" can have
different meanings\values, depending on the application requirements.
Ensure that the chosen API provides for the desired\required retrieved
value; i.e. take care to choose an API, from which to obtain the user-ID
value, that appropriately and consistently satisfies the specific
requirements. The job-user, the current-user, the submitted-by-user,
and various conceptual session-user or client-user values could all be
different; and any one of those could be the value that should satisfy
the "user-ID" requirement.
As an Amazon Associate we earn from qualifying purchases.