module moves on i5
Application security, Auditing, Compliance, CRM, Database, Development, Disaster Recovery, Encryption, Exchange, Instant Messaging, Networking, Policies, Risk management, Secure Coding, Security Program Management, Tech support
I wanted to check on a possible solution for a problem we have run into with our module moves. Cause of audit requirements we can't have pgmr's in the productions systems. So as a work around I have them creating their code in sourclib on the test partition then I have operations copying it into a production library on the test partition then moving it to the production system. I went that route because auditors said that the programmers couldn't compile their own code because they thought they could hide some source. My question is this the best way to handle this move? Is there a cleaner way?
Software/Hardware used:
Software/Hardware used:
ASKED:
July 27, 2005 10:40 AM
UPDATED:
August 3, 2005 8:17 AM
Answer Wiki:
What you need to do (by the letter and spirit) is to get into what is called "Release Engineering" or "Release Administration".
What it amounts to is isolation of the programmers from the production systems - with controls to make sure that what the programmers wrote is what you're duplicating.
The key steps involved here are:
Archival of changes (RCS, VCS) in a verifiable manner - There are both commercial and "free" versions of source code version/revision control systems.
The programmers can compile their own code - simply because they need to make sure that it does what they intended - but - then they submit all source code, make files, etc. to the RA/RE folks who essentially clone the programmer's development environment, and then compare their binary output to what the programmer submitted.
This covers not only the possibility of "hidden" source code, but also the more likely and common omissions of a forgotten header file, compiler upgrade or other trivial error that might result in the final product not being what the programmer intended.
Properly done, this also covers the organization from the "hit by a bus" or disgruntled employee scenario.
On a slightly humorous note - there's a cartoon that shows a widow weeping over a gravesite, and a man speaking to her saying "I know this is a difficult time, but did he ever say anything about source code?"
Hope that helps,
Bob
To see all answers submitted to the Answer Wiki: View Answer History.
You need a Change Management Product.
We use MKS Implementer.
http://www.mks.com/products/implementer
I hasten to add that this product serves our purposes on the iSeries, you will need to undertake your own assessment.
Miles
We also use MKS Implementer. Our developers do not have authority on production systems to perform any changes. They create and test on a development system which is set up to transfer the program changes to production. Production Control actually moves the code from dev to prod.
On a separate note, for after-hour emergency needs we have created an ID called “emergency” which allows the developers to perform the required changes after they have provided required information (trouble ticket, etc.). We have the ID set up so that it automatically becomes disabled immediately after the log in and the ID must be reset for each use. We also use journaling which captures all log information for auditing purposes.