Re: SQL statements for physical and logical files

I imagine someone can make a decent security argument that can be made as
to why it works like that.

I did scratch my head when I learned that it seems to apply to the entire
call stack.

I think trying to predict future call stacks can easily lead to analysis /
paralysis.

That said, those with higher security requirements may need to delve
there. For my applications, I don't need to.

Mike


date: Mon, 13 Feb 2017 11:18:17 -0500

from: Rob Berendt <rob@xxxxxxxxx>
subject: Re: SQL statements for physical and logical files

I feel you. I, too, would specify READS just because it feels right. But
this requirement that the whole stack matches is odd as heck.

Of course, if you really feel strongly about it then one could write up an
RFE at
https://www.ibm.com/developerworks/rfe/


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com


From: Mike Jones <mike.jones.sysdev@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 02/13/2017 11:09 AM
Subject: Re: SQL statements for physical and logical files
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>


I think Rob is likely correct.

I put MODIFIES SQL DATA on all SQL functions and procedures, because when
I
make an SQL component I don't want to try and predict the future in terms
of what other types of objects are in the call stack when I call said
object in the future. I may only need to call an SQL object today in a
read only call stack, but down the road I may want to call the same object
in a call stack that is modifying data. That exact scenario happened to
me
about 5 times until I decided to switch to consistently using MODIFIES SQL
DATA. Overkill perhaps, but I no longer see those types of errors.

Mike