Re: AW: Can I create an ALWUPD/ALWDLT *No file with embeded SQL?

Glad to here you have tho options figured out. I missed that this would
run somewhere else. Sorry about that.
Maybe IBM needs to give a system setting that they would need to be called
to reset, allowing restricted file access for QSECOFR for cases like this.
Qsecofr could still maintain the system even files (create/delete) but no
actual data access. That might make this new auditor driven world easier
to work in.

I still don't understand that,executives steal from the company, Auditors
miss it or allow it based on current practices. So, to fix this problem we
make more auditing.
I know in reality its more complicated than that. just venting whenever I
here auditors requiring things.

I love the journal Idea. Its safe. The auditors want to see what happened
print out the journal and let them read it. then instead of asking me they
can always go back to the printouts and see what happened. I can't change
the papers they have in their possession.




eduard@xxxxxxxxxxxxxxxxxxxxxxx
Sent by: rpg400-l-bounces+broche=packagingcorp.com@xxxxxxxxxxxx
05/30/2007 11:10 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: AW: Can I create an ALWUPD/ALWDLT *No file with embeded SQL?






Yes, we do not trust the QSECOFR on the boxes where our application runs.
Auditters have also the tendency to not trust QSECOFR.
Our QSECOFR we trust. Someone elses QSECOFR we might trust but better sure
than sorry.

Not necessarely this file must be created with SQL.
SQL was one of the possible options to create a externally described file
on the fly.
Doing things from a source and compiling this is not an option because:
- We do not have that environment under our control.
- Do not know what features they have installed (can we compile?).
- Source can be changed (we do not use any scripting language either) and
that is far to risky.

So now we have decided on Copy and Check tricks.
All files that need handling have a parent file (with the right atributes
set).
When needed we Create a new file based on the Parent.
When using the file we check ObjectCreation date/time to check if we have
created the file (and not someone else).
This procedure is not fool proof but you will need the manual (what
manual?) to fiddle with it.

Regards,
Eduard,


----- Original Message ----
From: Bob P. Roche <BRoche@xxxxxxxxxxxxxxxxx>
To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, May 30, 2007 11:34:02 AM
Subject: Re: AW: Can I create an ALWUPD/ALWDLT *No file with embeded SQL?


Sorry, but I always wonder why people need to prevent QSECOFR from
doing something. If you can't trust your "SECURITY OFFICER", you have
bigger problems. QSECOFR should never be restricted, in my opinion. The
whole point of this profile is to do things no one else can.If have a
problem later and need to do something, I never want to here someone say
call IBM to fix that. No one, not even QSECOFR can do that. We secured
that option. QSECOFR should have all access. you then secure the QSECOFR
profile.
I know this still leaves you the problem of securing the file, as
the original question asked. I have one question. Why do you have to
create it using SQL? From what everyone has said, DDS will give you what
you want. Just use the right tool for the job. In this case, DDS for this
particular file.




"Raul A. Jager W." <raul@xxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/30/2007 10:20 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: AW: Can I create an ALWUPD/ALWDLT *No file with embeded SQL?






This will work until somebody uses "GRANT".
How can we keep everybody (even QSECOFR) from giving a GRANT or CHGAUT?