Re: Is there an easy way to retrieve the user-ID in an iseries COBOL ILE pgm?

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.