Mainframe, MVS and zOS Discussion

Hi,

Assume there is a program1 which has got changes. We have our team divided in 4 different locations. Now, all of us are making changes in this program for different requirement. Every one has retrofitted the code changes for other teams and doing UAT. But in case, we go for production deployment and for a team the changes needs to be backed out so how do we back-out only the impacted changes? Is there a good practice to do it?

a good practice would have been not to have 4 teams modify at the same time the same program

There is no defined good practice for what you have done. In the future, do not allow 4 groups to update the same program. Many source code management systems allow only one check out at a time of a given program, which is one way to prevent the situation you're in.

Robert Sample wrote: ↑Thu Apr 26, 2018 9:01 pmn the future, do not allow 4 groups to update the same program.

Robert, you should know better than to write this*. This is nor practical.

This is why we have Version controlling in place ..

Your shop architecht should have designed the changes in the right order for releases...

But To me too many cooks spoil the broth

[ Post made via Android ]

Rima Bali wrote: ↑Thu Apr 26, 2018 8:06 pmAssume there is a program1 which has got changes. We have our team divided in 4 different locations. Now, all of us are making changes in this program for different requirement. Every one has retrofitted the code changes for other teams and doing UAT. But in case, we go for production deployment and for a team the changes needs to be backed out so how do we back-out only the impacted changes? Is there a good practice to do it?

Release Management at your shop has to come in to the picture for the situation, you describe. This is the strategy your shop has to define. In a typical situation - one or more programmers, will update the same source of code but which newly developed code should be promoted to next level (for example, QA or UAT) must be a collective decision by the team supporting the software.

No version control tool can magically merge (retrofit) the code from different resources, it has to be done manually, AFAIK. Though some of the version control tools can let you know that a given program is being modified by different programmers and might tell the 'package' in which it is being modified.

zprogrammer wrote: ↑Sat Apr 28, 2018 6:53 pmThis is why we have Version controlling in place ..

But can a version control tool merge the changes form different programmers?

Robert Sample wrote: ↑Thu Apr 26, 2018 9:01 pmThere is no defined good practice for what you have done. In the future, do not allow 4 groups to update the same program. Many source code management systems allow only one check out at a time of a given program, which is one way to prevent the situation you're in.

Thanks. But we are not using any version control tool. We send an email to everyone saying that we are reserving the program for us. But then others also send the similar email.

Then you (the company) needs to change its way of working. At the moment you are a catastrophe waiting to happen. If you have clients then they would be wise to move elsewhere.

I agree with nicc -- your company is just begging for problems with the current approach. It is far too easy for changes to be lost with your approach.