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 (https://ideas.ibm.com).
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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
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 Suspend Timeout actions give the user control of what should occur in the event that we cannot reach a suspended state within the given timeout period.
CHGASPACT OPTION(*SUSPEND) will perform the following steps. Note that suspending ASP activity ONLY halts database activity within the ASP and other, non-database-related reads and writes can still occur. As such, ALL *SUSPEND activity should be considered a "Best We Can Do" state. The only truly quiesced state would be if the IASP were fully varied off (or the system powered down in the case of suspending *SYSBAS)
1. Force Write. This scans every page in memory, searching for in-flight data that has not yet been written to the ASP and flushes it to disk. This is a "freebie" operation and the timeout parameter is not applied, since nothing has actually been suspended yet and all disk activity is still ongoing.
2. Suspend Transactions. This halts the initiation of all new commitment control transactions and waits for up to the suspend timeout value for current transactions to reach commit boundaries. This is the step that is most likely to exceed the suspend timeout value.
3. Suspend non-transaction-based database operations. This halts the initiation of new DB operations outside of commitment control. Non-transaction-based DB operations are quick and we wait for up to 10 seconds for the existing operations to complete.
4. Force Write. We do a 2nd scan of memory and flush any outstanding/in-flight memory to disk in order to get all of the data that had been changed while steps 2 & 3 were running. Essentially we are getting all the updates that have occurred while we were suspending activity.
At this point, the ASP is Suspended. No database activity should be ongoing within the ASP. Now, this is NOT a perfect "all data has been flushed and no activity at all is occurring" state. There are non-database reads and writes that can still occur within the ASP. This means the ASP is really in a "Best We Can Do" state of suspension here.
Now, what happens if we cannot reach this "Best We Can Do" state where database activity is halted within the suspend timeout period? The Suspend timeout action parameter takes effect. There are currently two options: *END and *CONT.
SSPTIMOACN(*END) -- this option will wait for the suspend timeout value for the ASP to fully suspend. If we cannot suspend all transactions or operations, we halt the suspend process and automatically issue a *RESUME -- effectively "undoing" the Suspend and leaving the ASP in a normal, read/write state.
SSPTIMOAC(*CONT) -- this option is equivalent to your proposed *BCD "Best we can do" option already. If we cannot suspend all transactions/operations within the given timeout period, we accept that all suspends are considered a "best we can do" suspend and continue processing the suspend. We move on to the next step (suspending operations or forcing writes to disk) and leave the ASP is an "as close to suspended as we could get it" state. At this point control returns to the user, so they can take a flashcopy of their ASP, perform a Save, etc. as they wish.
Once the activity is completed, the user should issue a CHGASPACT(*RESUME) in order to allow database activity (transactions and operations) to write to disk again, thus freeing up all jobs that were attempting to access the ASP and allowing them to continue running.
We have a 10-minute "safety valve" timer that will automatically resume database activity if a manual *RESUME is not issued. This timer should not be confused with the SSPTIMO(xx) parameter. The suspend timeout parameter defines how long to wait for existing transactions and operations to complete (how long to wait for the suspend to occur). The safety valve timer is used to automatically allow database writes again AFTER the suspend has completed.
This is especially important if the job performing the CHGASPACT *SUSPEND happened to attempt a database write while in the suspended state. If that were to occur, that job would also "hang" waiting for the write to complete and therefore would be unable to perform the subsequent *RESUME in order to allow activity to continue again. Essentially it's a way of releasing the system if all sessions happen to hang due to the *SUSPEND.
IBM Power Systems development
The CAAC has reviewed this IBM Idea and recommends that IBM view this as a “nice to have” low priority feature.
This has benefit to shops running PowerHA and may also benefits Flashcopy shops.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual IBM Ideas on the broader IBM i community and has therefore reviewed your Idea.
For more information about CAAC, see www.common.org/caac
Carmelita Ruvalcaba- CAAC Program Manager
CEAC has discussed this idea and thinks that the desired behaviour can already be achieved as the system should post a message when the timeout has been reached without reaching suspended status.
Background: The COMMON Europe Advisory Council (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
Sabine Jordan + Sara Andres – CEAC Program Manager, IBM