This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
IBM Power Systems Development - RDi team
Thank you for your suggestions.
I'm fully aware that it can be bypassed in the PDM.
Thus being very carefull when doing something in the PRDLIB ie scanning in it.
While waiting for IBM's solution (which could take years, if ever), here's a suggestion:
Create a new test source file in the production and test environments (so everything already there will work as before).
Create a new user profile that will have *ALL authority for the new production test source file.
Change the authority of the new production test source file so that all users have only *USE authority (including *PUBLIC but not the new user profile which has *ALL authority).
To move source from the new test source file in the test environment to the production environment, log on as the new user profile and run your third party app.
You can do this as a proof of concept with just the one new source file (no need to modify the library's authority). If the concept works, then you can apply it to the other source files in the production environment and your problem will be solved, or you can wait until IBM provides a solution, assuming they do.
By the way, the production source files could be edited with PDM directly by bypassing your third party app, which is what RDi is doing.
First of all the source management system is a third party green screen environment. And it is old.
If you try to edit a source it checks if a specific object exists in the library.
If it does you are allowed to open the source with PDM.
Otherwise access is rejected.
Compilation is also controlled via this system.
I don't dare changing object level authority on these libraries and will not be allowed to do so.
Because I risk all hell breaks loose.
You stated "You can only browse the sources in the source library it is not possible to edit them." How is this being done if not by object level security (rhetorical question, it can't be done)? Unless you have object security on the production source files, that statement is false, if they can be edited by RDi, then they can be edited by any other means of editing source files.
If it causes other problems your procedures/way of working is not correct.
I suggest to solve this first.
Implementing object level authority will cause a lot of other problems. So this is not an option.
No need for any of that, just use object level authority. Change the authority of the source files to *USE for *PUBLIC and any user that has specific authority to the source files. RDi allows users with *USE authority to open source members in browse mode only, you'll get an error if you attempt to edit a source member.