Inclusive vs Exclusive PD vs PY

Anyone,

Our row security is currently setup exclusive.

We're looking at setting up Inclusive and I want to do some inclusive testing in PY while leaving PD alone. Doc ott-01-0099 states that security must be one or the other, but I think I remember reading that doesn't apply across environments as long as I have my PY and PD looking at different F00950 tables via OCM.

Anyone?
Thanks
Brad

ERP8 on SQL 2k

[ QUOTE ]
Anyone,

Our row security is currently setup exclusive.

We're looking at setting up Inclusive and I want to do some inclusive testing in PY while leaving PD alone. Doc ott-01-0099 states that security must be one or the other, but I think I remember reading that doesn't apply across environments as long as I have my PY and PD looking at different F00950 tables via OCM.

Anyone?
Thanks
Brad

ERP8 on SQL 2k

[/ QUOTE ]

I'm not sure that E1 follows OCM rules for F00950. I may be wrong but look into it.

It is THEORETICALLY possible to do this using different .INI files - providing you also set up two servers (one for DV/PY, the other for PD). However, now you're in effect managing two completely seperate implementations - and of course you can start to see the issues involved.

A much, much easier method is to give your developers/testers two user ID's - one that they can use to gain access to production (with lots of security attached) - the other they use to get into development/PY (with little security).

In that way, your poor CNC administrator only has to work their regular 12 hours a day....

Brad

In EOne, security applies across all environments. If you want to test out Inclusive, you will need to test it on a different instance, and then apply it to your production instance.

Gregg

Brad,
We did exactly what you are suggesting. On Xe. We have DV/PY (we call this Test) pointed at one F00950 (with OCMs, and yes it works as expected) and PD pointed at another F00950. We inserted the record to flip to Inclusive Row Security into Test and it did not impact Production.

We actually did this to extract SQLs from a variety of applications, update, insert, search stuff and then took those SQLs to PD to try and compare the performance impact of exclusive vs inclusive vs no row security. After about a weeks worth of effort the results were....inclusive!!
And if you are trying to do the same thing, maybe I can save you the effort. There are just too many variables to be able to measure the impact. You may get some results that could change the next day based on your data distribution in the files that you are applying row security to. You should be basing your decision on what makes the best sense for how you want to set up your security.

We have extremely large files so generally avoid row security like the plague and do things like putting DB2 views over tables and then using OCMs to point specific user groups to those views instead of the real files. Of course this is not possible in 8.9 and higher as OCMs by User Group don't work. (multiple roles - which OCM would the system use?).

Hope this helps. Good Luck.

Sue Shaw
Xe SP23J1 iSeries Coexistent

I just reread my post and I made a huge typo.

The sentence that reads
"the results were inclusive!!'

SHOULD READ
"the results were INCONCLUSIVE!!'

Big difference in meaning. Sorry about that.

Sue.

Sue,

I assume your inconclusive results were speed related?

I'm not looking at this as a performance issue as much as I am a security stand point. I want security to be denied if a record is accidently deleted or omitted during setup of a new or current user, currently security is granted in those circumstances.

I will add the record to my PY F00950 during off hours and make sure it doesn't affect my PD before proceding.

Thanks for the input,
Brad