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.
The BRMS team has previously requested more clarifying information. Because the additional information was not provided within 30 days, the request has been closed.
Using the RSTOBJBRM OPTION parameter (*OLD) should still be a valid even though it requires the loading of an older volume. The parameter is used on the native RSTOBJ command that BRMS issues under the covers and it should not restore any older files that were deleted.
.
Sorry, my previous comment has not been posted ...
I start again :
I agree with you about the operating principle of the RSTOBJBRM.
I need a few times, to restore all the objects for example of type * FILE, which were saved on my last backup.
Currently with RSTOBJBRM, I can not do it, because if an object of type * FILE was not present on my last backup (because deleted, because no more need), BRMS, then asks me to mount a cartridge on which was still present this object.
this cartridge is not good because not the last, and my * FILE type files will not be good.
What would be necessary to solve my problem, is to add an additional parameter in the command RSTOBJBRM.
If YES: Then the operation of BRMS remains as it is.
If NO: Then we restore the objects (for example of type * FILE) present on my last backup (cartridge). in this case BRMS must not take into account the details of saving objects.
Other remark:
It would be nice to add a parameter in your RSTLIBBRM command, in order to be able to select the type of object to restore (* FILE, * DTAARA, etc ...)
RSTLIB allows it.
When saving with object level detail and using RSTOBJBRM, the current behavior seems correct. This request does not fit well into the way RSTOBJBRM is intended to be used. For this specific backup environment since it appears to be doing full library backups and a full library restores, is saving object level detail really required and could the backup strategy be changed to fit the expected behavior. Can this be automated using RSTLIBBRM instead. It doesn't seem like there is a need to have individual object tracking.
Please comment to this RFE to let us know if this recommendation is sufficient for your Use Case. If so, we will consider changing this to be Delivered. If not, let us know why RSTOBJBRM and object level detail tracking is required in your environment.
Hello.
this will allow me to automate in my exploitation work the automatic delete of some specific libraries.
Regards.
Hello.
I just tried with the OPTION parameter (* OLD), and my problem remains whole.
The work falls into MSGW, and asks for an old cassette volume.
"000416 Cartridge not found
Volume sets not available on TAPMLB01 units. (C G)" ?????
==>>my most recent volume is the 000437
000415 0001 *ACT 28/01/19 COFFRE 14/03/19 LTO7
000416 0002 *ACT 22/02/19 COFFRE 14/03/19 LTO7
000404 0003 *ACT 16/03/19 TAPMLB01 *NONE LTO7
000412 0004 *ACT 07/04/19 TAPMLB01 *NONE LTO7
000436 0005 *ACT 27/04/19 TAPMLB01 *NONE LTO7
==>> 000437 0006 *ACT 03/05/19 TAPMLB01 *NONE LTO7
The BRMS team needs more information to further assess your Request for Enhancement. There is currently an OPTION(*OLD) parameter on RSTOBJBRM which will only restore objects that exist on the system at the time of the restore. Have you tried this using this parameter and does it meet your expectations?