Skip to Main Content
IBM Power Ideas Portal

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 (

Shape the future of IBM!

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:

Search existing ideas

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 your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Delivered
Workspace IBM i
Categories BRMS
Created by Guest
Created on Dec 13, 2016

User-defined timestamp in Full System Flash Copy - *SYSBAS support

Have the possibility to set the User-defined timestamp in Full System Flash Copy to have the correct reference for the incremental backup

Use Case:

We want reduce the backup time on Flash copy system in order to use for our test.
For example:
the flash copy is start at 0:00
the flash copy is up at 0:28
the backup start at 00:37
the allusr start at 1:27
the ifs start at 7:02
if anything is changed between 0:00 and 1:27 for any library or between 0:00 and 7:02 for ifs these object are considered changed before the backup so next incremental data will not save them

Idea priority Medium
  • Guest
    Jan 24, 2018

    This was delivered in the following BRMS PTFs : 7.3-SI65676 7.2-SI65675 7.1-SI65674

  • Guest
    Dec 11, 2017

    This request should be marked as "delivered" now.

    2017-09-15: 7.3 SI65676- 7.2 SI65675- 7.1 SI65674


  • Guest
    Jun 16, 2017

    For us that use full system flashcopy backups, either with the Full System Copy Service Manager, manually as described in the IBM developerWorks or with an inhouse created program, this must be one of the most important feature we need. I think the priority of this feature request should be high instead of medium.

    At our shop we have objects that are only changed during the nightly batch runs and during the same time the full system flash copy backup is in progress, so we can not use incremental backups as those objects only will be saved during the full backup.

    As the save times in the BRMS database does not reflect the time the flash copy was made you also need to think twice in case you need to restore an object, both the time and date may differ for the one you select.

    Please, implement this feature as soon as possible, we really need it.

    Thanks in advance.

  • Guest
    May 1, 2017

    Just to restate, the changes that occur after the flashcopy has completed are not saved by the full backup that runs immediately after the flashcopy since they occurred after the flashcopy but the next incremental save will go from the completion of the full backup, not the completion of the flashcopy, and such will NOT pick up those changes that fell into the void between the flashcopy completion and the full backup completion.

    Recategorized by Tom Duncan

  • Guest
    Dec 14, 2016

    We agree with this request and will try to support this at some point in the future.

  • Guest
    Dec 14, 2016

    This RFE's Headline was changed after submission to reflect the headline of an internal request we were already considering, but will now track here.