MONSWABRM

Hello IBM_Systems_Developer,

If FlashCopy is your strategic direction, what does this mean if you are using BRMS in an internal disk solution only?

Greetings Rudi

The BRMS team has again reviewed the request to offer a secondary command when the MONSWABRM wait time is not reached. In a backup environment where save while active synchronization is not consistently achieved, there are other alternatives including FlashCopy backup which is our strategic direction. Thank you for your input but we will not be implementing this request and will therefore close the RFE.

Hello IBM_Systems_Developer,

After having had a discussion with the customer, they would like to know what the idea is behind always run the command. The thing is that you want to know what the status if after you get out of the MONSWABRM command.

Is that because of the fact that the sync point was reached or was it because the time out was the reason?

That is the information you need. For the customer it is obvious that in those cases it is very unlikely that you want to run the same command. He even said: "what is the use of having the command option in the MONSWABRM command, if afterwards you always want to run the same command.

Bottom line is that our customer does not see this as a solution, he prefers the option to have a command if the sync succeeds and a command if the sync times out, please.

Greetings Rudi

The BRMS team would like a confirmed response to our proposed solution. Have you been able to verify with the customer if they agree with a change to always run the current command instead of adding a new command interface?

Hello IBM_Systems_Developer,

Thanks for the update and re-investigating.

To be honest I am not sure about this. Please let me get back to the customer and discuss this with them.

Greetings Rudi

The BRMS team needs more information to further assess your Request for Enhancement. After receiving customer input, BRMS has chosen to re-investigate this request.
The BRMS team would like input on a possible implementation change to always run the current command instead of adding a new command interface. The existing command could call a customer program which could handle any logic issues which required different behavior depending on a failure or timeout. This new behavior would not "do nothing" in a timeout or failed case, instead it would always run the command. BRMS could update the help text in the next release to state it runs the command at the end
of the MONSWABRM processing which includes after a failure or after the timeout specified. Would this be an acceptable behavior change?

Hello IBM_Systems_Developer,

What the recovery command does is up to the customer. It could be anything. In the cases I have seen it go wrong, the recovery was to start the what was stopped beforehand. This procedure needs to have all the checking in it, in the case BRMS is still active. that is the responsibility of the customer/ Not offering this functionality based on what might go wrong in that command is speculation because I could put a command there which just sends out an email alert to the person on duty. With a link to the recovery procedure. That is harmless. So I do not understand why this RFE is rejected based on the assumption I put in the wrong command, doing things which are not clever and overlooking the fact that the BRMS backup might be still active.

Greetings Rudi

The BRMS team does not intend to provide a solution to this request at this time, so it is being closed. MONSWABRM today supports a wait time, which tells BRMS to wait for the checkpoint message and if not received in the given time, to end the monitor job. This function works today. The MONSWABRM job simply ends in this case because BRMS cannot know if or when the checkpoint will occur. When the checkpoint is not reached in the MONSWABRM wait time, if MONSWABRM were to offer a secondary command to run, to start the subsystem for example, there is risk that the application may fail to start or something may go wrong with the backup which is still active at that time. The BRMS team does not believe adding a secondary command to run when the MONSWABRM wait time expires is the correct behavior. This would be problematic unless BRMS were to force the backup to fail and end the control group. Forcing the backup to fail seems too complex to fit every environment and therefore is not worth the risk.

The BRMS team will use this request as input to planning but no commitment is made or implied. The request will be updated in the future if the request is implemented. The BRMS team will use votes and comments from others in the community to help prioritize this request.

The COMMON Europe Advisory Council (CEAC) has reviewed this requirement and recommends that IBM view this as a high priority requirement that is important to address.

This RFE was originally raised by CEAC in 2015, reference AR0187 on old requirements database.

Background: The CEAC members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

Therese Eaton – CEAC Program Manager, IBM