PowerTech's Authority Broker

First off this is not a sales pitch for Authority Broker nor am I with
PowerTech any longer. It is simply an FYI for those who use it.

Ever wish you could use PowerTech's Authority Broker product within stored
procedures? Well you can by writing two relatively simple exit programs.
At present I do not have access to a system so I can't provide the actual
code so I've provided some pseudo-code.

The first program you write is a Before Switch exit program. In it you
obtain profile handles for the job's user (who started the job) and the
job's current user (the profile the job is currently running as). Here are
the essentials for this program.

1. Use the current user profile handle generated in the previous Before
Switch exit program invocation to call Security API Release Profile Handle
(QSYRLSPH or QsyReleaseProfileHandle). This step eliminates the possibility
that the number of profile handles generated does not exceed the maximum
number of profile handles per job. If it is the first time through there
will be nothing to release.

2 Use Work Management API Retrieve Job Information (QUSRJOBI format
JOBI0600) to obtain the job's current user profile.

Offset
Dec Hex Type Field
0 0 BINARY(4) Number of bytes returned
4 4 BINARY(4) Number of bytes available
8 8 CHAR(10) Job name
18 12 CHAR(10) User name
28 1C CHAR(6) Job number
34 22 CHAR(16) Internal job identifier
50 32 CHAR(10) Job status
60 3C CHAR(1) Job type
61 3D CHAR(1) Job subtype
62 3E CHAR(8) Job switches
70 46 CHAR(1) End status
71 47 CHAR(10) Subsystem description name
81 51 CHAR(10) Subsystem description library name
91 5B CHAR(10) JOB'S CURRENT USER PROFILE **** value to generate the
profile handle for ****
101 65 CHAR(1) DBCS-capable
102 66 CHAR(1) Exit key
103 67 CHAR(1) Cancel key
104 68 BINARY(4) Product return code
108 6C BINARY(4) User return code
112 70 BINARY(4) Program return code
116 74 CHAR(10) Special environment
126 7E CHAR(10) Device name
136 88 CHAR(10) Group profile name
146 92 ARRAY(15) of CHAR(10) Group profile name - supplemental
296 128 CHAR(10) Job user identity
306 132 CHAR(1) Job user identity setting
307 133 CHAR(15) Client IP address - IPv4
322 142 CHAR(2) Reserved
324 144 BINARY(4) Offset to time zone information
328 148 BINARY(4) Length of time zone information
CHAR(*) Time zone information (See Format of Time Zone Information
for more information.)

3. Use Security API Get Profile Handle (QSYGETPH) to obtain a profile handle
for the job's current user (Dec offset 91).

4. Save the current user's profile handle in a manner where it can be
retrieved by the second program (data area, data queue, environment
variable, etc.). You will need it in the second program.

5. Use Security API Get Profile Handle (QSYGETPH) to obtain a profile handle
for the job's user (Dec offset 18).

6. Save the profile handle in a manner where it can be retrieved by the
second program (data area, data queue, environment variable, etc.). You
will need them in the second program.


That's all there is to the first program.

In the second program you are going to reset the job's current user back to
what it was prior to Authority Broker switching profiles. The second
program is an After Switch Release exit program. Here are the essentials
for this program.

1. Use the current user profile handle generated in the Before Switch exit
program call Security API Set Profile Handle (QWTSETP or
QsySetToProfileHandle). This will switch the job to run under the authority
of the current user that was in force when the Before Switch exit program
ran.

2. Use the job user profile handle generated in the Before Switch exit
program to call Security API Release Profile Handle (QSYRLSPH or
QsyReleaseProfileHandle). This step eliminates the possibility that the
number of profile handles generated does not exceed the maximum number of
profile handles per job.

Authorization assignments to these programs is determined in the same
fashion you would for any other job using Authority Broker. With stored
procedures remember that ODBC/JDBC jobs are not started by the user signing
on. QZDASOINIT pre-start jobs are started by QUSER so QUSER will have to
have *USE rights to the second program.

Both programs can be owned by a profile with enough authority to use the
API's I've mentioned. Creating the programs with the user profile parameter
set to *OWNER.

- Gary Monnier