Re: WFL usercodes

On Tue, 30 Aug 2011 06:18:49 -0700 (PDT), dgathman@xxxxxx wrote:
How can I determine the usercode the job is running
under, USER1?


The job is not running under USER1. It's running under USER2. The
display is correct.

It would help if you'd come back and tell us what you are trying to
do. In the mean time, "running under" a usercode means these things:

1) When the job (or subtasks) open files, by default they open files
under the usercode's directory.

2) The job and subtasks inherit the permissions of the usercode, most
importantly in terms of file and database access.

3) The log entries for the job indicate the usercode. This is most
significant when doing cost accounting.

4) Messages generated by the job and subtasks may be routed to
terminals logged on with the same usercode (but are not always).

Ref #4: if the job were running under USER1, it would display "USER1"
.... but assuming you are logged on to USER2, you would not see the
message, since messages for USER1 are not shown to USER2. That's a
clear indication that it is actually running under USER2.

As others have pointed out, START (USER1)WFL/blahblah only accesses
the file under USER1 as the source for the job. To do this, USER2 must
have permission to read the file, which by default it does not. So
either USER1 has set the permissions on the file to PUBLIC (or any of
various more complex options), or USER2 is a privileged user. The
latter is a Very Bad Idea except when it's absolutely required (it's
equivalent to being root).

There are at least four built-in ways to actually run that job under

1) Be logged in as USER1 when you start it. (It appears that this is
what you are trying to avoid.)

2) WFL START (USER1)WFL/blahblah;USER=USER1/pw

3) WFL USER USER1/pw;START WFL/blahblah

4) Hard-code the usercode and password in the WFL being started.

5) Use special tasking privileges.

Note that #2 and #3 are distinct in the way they operate, despite the
surface similarity. #2, #3, and #4 have the obvious disadvantage of
needing the password stored in plaintext.

So giving advice really requires knowing what you are trying to do. If
this is a case of jobs in one usercode depending on jobs in another
usercode, you need to consider whether the application really should
be running under a single usercode. If you are writing a utility
program, for example a job scheduler, there are ways of giving it the
needed permissions to do this without storing the passwords -- but
doing that safely requires a lot more knowledge about MCP systems than
you have.