Securing Source Physical File Members

[Guest.Visitor]

Is there a way I can secure a member of a physical file? I am trying to prohibit access to source physical files for source that is in a test environment. Once the source is moved into the test environment, I want to make it read only to programmers, and *ALL access to the person responsible for moving tested code into production. Any ideas on how I can accomplish this?

[Guest.Visitor]

Securing Source Physical File Members

Doug, There is no easy way that I know of to secure only members. You can use a change management system to track and prevent unauthorized changes from making it to production. One possibility might be to secure the source with a super-source user profile and build tools that adopt the super-source user. That is a lot of work and may make it harder for your programmers to do their job. I would consider auditing and a source comparison utility, which would be much less intrusive. David Morris

[Guest.Visitor]

Securing Source Physical File Members

Why not make the source code read only to programmers all the time? Allow the change administrator to change / replace the source data, but only allow the programmers to read the data to their own library. This is a fairly frequently used security design, and can help to ensure the integrity of your production objects. jte MC Security Editor

[Guest.Visitor]

Securing Source Physical File Members

Doug, This may be answered in the existing posts already, but I would like to add my 2 cents. There is no easy way to secure just a member of a file that I am aware of. I asssume you are attempting to manage an implementation system of multiple layers of access. It appears that you want the programmers to write programs, the tester to test programs and the implementer to implement programs. I would create two new source files. One for the testor, one for the implementor. After the programmer is finished, the implementor could then copy from the programmer's source file(s), the source(s) required. Then compile and test. Once he/she is happy, the implementor is informed, who then copies the file member(s) to the production library source file(s). At this point he/she schedules and compiles the objects and goes from there. It involves two additional levels of security. One that allows the testor to get to the programmer's libraries, and the implementor to get to the testor's libraries, while restricting the programmer from the testor and implementor libraries. The testor needs to be excluded from the implementor and live libraries as well. -bret

[Guest.Visitor]

Securing Source Physical File Members

Doug, What you are trying to do is implement some kind of Change Management. The easiest way is (as already stated) is have the production source files owned by a special profile. That profile is the only one that can change the source. The problem with this is that someone will have to be designated to move source to production. The alternative is to purchase a Change Management System. There are some that are very expensive and comprehensive (Like Aldon's CMS) and others that are less expensive but still give good management and flexibility (like Softlanding's Turnover). The third choice is to write a Change Management System of your own (basically keep track of who has the source and use a specific command to move source to production) Not knowing the size of your department and the amount of developement you have on-going it is hard to give you a specific direction to go in.