You are right. We have excluded LMTUSR from the library the trigger
resides in. The application behaves exactly as you describe in your
first paragraph below. If the security audit confirms it, I see two
alternatives--1) move the triggers to a library that LMTUSR does have
authority to access or 2) use a data queue to send information to
another job whose user does have authority to the libraries. Am I
missing any alternatives?
And now I really have to get to that meeting... :(
Roger Mackie
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Ed Fishel
Sent: Tuesday, April 03, 2007 10:12 AM
To: Midrange Systems Technical Discussion
Subject: RE: Adopted authority and triggers
Roger Mackie wrote on 04/03/2007 09:52:56 AM:
It was my understanding that IBM recommends the trigger be in the same
library. It caused us (more severe) problems when they weren't.
I am not suggesting that you change this design. I was only suggesting
that if the trigger program is in this library that, then a user will
not be authorized to call that trigger program if you have excluded them
from that library. If this is the case, then even if the trigger program
adopts authority from QSECOFR, it will not help because the not
authorized problem is occurring before the trigger program has a chance
to run.
I still think the best advice I have give you today is to use the
security audit journal and the job log to determine the exact problem.
Ed Fishel,
edfishel@xxxxxxxxxx
midrange.com
