RDA Security

[lgould]

We are currently using a 820 AS/400 4 way as our enterprise server and =
running XE service pack 14.1.=20

We just started using the report writing tools in OW. We wanted to setup =
security to prevent users from accessing some more sensitive tables and =
also to prevent them from updating, adding and deleting records in tables. =
Only allowing them to read records and also export data. When talking to =
JDE technical support, they told us RDA security options were very =
limited. Does anyone have any ideas to how we could accomplish this. =20

Thank You,
Leo =20
=20

 

[Larry_Jones]

Leo,

the answer is to NOT give users RDA as a reporting tool.
If you have any concerns re data integrity and data confidentiality do not attempt to use this batch programming tool as a end-user report writing tool. In addition you are doing these same users a dis-service by giving them RDA as a reportwriter instead of a real report writing tool.

You can tell that I'm a little opinionated about this, can't you? ;-)

Suggest you search the forum archives on "reportwriter" or "RDA" to get more ideas on this. This subject has come up before.

Regards,

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials

 

[Zoltan_Gyimesi]

Hi Leo,

Larry is right as usual.
RDA is not really a "Report Writer" tool but a powerfull "Batch Programing" tool. It has much less reporting features (hard to position correctly, difficulties using fonts, font types, etc., can not handle graphics, etc.) than batch programing features. You can destroy tables with minimal programing needs and skills using RDA!

Don't let you mislead by the name RDA. Let see:
RDA: Report Design Aid
...AND... what will it produce?
UBE: Universal Batch Engine

I do not know anyway to limit the possibilities in RDA for users. Sorry.

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)

 

[njc]

Leo ...

We were faced with the same situation. Here's what we did.
1. We created a separate environment known as 'adhoc' with DV path code and a copy of production data that is automatically refreshed every night. No mistakes in updating.
2. If the user needs immediate access for a one-time, the Development group will create the report for them. If the user develops a report that needs to run daily, he/she submits a request for the report to be production (including the associated documentation in our format). If accepted, we make changes as applicable and then it is ours to maintain.
3. We created separate development ids so that the user does not have access to production when in development mode. We applied the same row security to the development id that the user has in production to stop access to sensitive data.
4. We also have a policy that updates to data (even in the adhoc environment) are not allowed and doing so (since it is not an accident!) is grounds for personnel action.
5. We use FAT clients and also PC Anywhere to a FAT client for development at remote sites.

We rolled it out as beta with 7 users (4 remote and 3 local) and now have 15 with access to the system. The users are pleased and we have had no problems to report.

I realize a report writer tool would be a better option, however, that was not an alternative for us, at least in the short term. We may consider that next year.

Hope this helps.

... Natalie




Natalie Chlop
Xe, AS/400, Citrix, SP15.1
Financials (Mfg/Dist target October)