Skip to Main Content
IBM Data and AI Ideas Portal for Customers

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:

Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

Additional Information

To view our roadmaps:

Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases

IBM Employees:

The correct URL for entering your ideas is:

Status Not under consideration
Workspace Db2 for z/OS
Created by Guest
Created on Mar 3, 2016

Log offload task needs to be manually cancelled restarted after outage to tape

We are seeing situations when tape processing is down and a DB2 request to offload logs to tape is initiated using dynamic allocation, that offload task will hang and never be satisfied until the offload task is cancelled and re-driven manually.

This poses serious and critical risks when we are performing maintenance on our tape infrastructure, or any other planned or unplanned outage. If an offload request occurs during the tape outage, the request is not satisfied. DB2 appears to wait indefinitely for the request to be satisfied. Since SMC is down while when the offload request is made, it is unaware that it needs to fulfill the request. In the meantime, logging continues on DB2 and subsequent offload requests stack up behind the first unfulfilled offload request. Many times, we are not aware of an issue until the active logs become full, waiting to be offloaded.

Is there a way to make DB2 re-drive the offload automatically? HSM, for example, has the ability to automatically re-drive tape mounts. Is there a way to make DB2 behave in a similar fashion?

Let me know if there is any information I can provide. I will attach a test scenario.

  • Guest
    Apr 28, 2021

    Hello, would like to confirm the latest guest comment from June 19/20. Long time ago we had similar situations. To reduce the space i also removed one side of archive logs so that archiving on that volume range continues. These days where we have virtuel drives and much storage where volumes also contains as cache storage we did't have such situation again.

  • Admin
    Janet Figone
    Apr 25, 2021

    Thank you for submitting this enhancement request. While we view all the enhancement requests we receive as valuable and we would like to implement all of them, in an effort to have maximum transparency we are closing the ones that don’t currently appear on our two year product roadmap. This is not to say that these enhancements may not still be implemented at some point in the future as we do evaluate our requirements on the basis of customer demand and technical impact, to deliver maximum value to our customers.

    We appreciate your input to the Db2 for z/OS development team.  And we hope that you will continue to submit enhancement suggestions for improvements as customer feedback is a key component to shaping the future direction of Db2 for z/OS. 


    The Db2 for z/OS Team

  • Guest
    Nov 24, 2020

    We have had this issue in the past.

    We now have automation that responds to DSNJ017 by issuing ARCHIVE LOG CANCEL OFFLOAD, which cancels the log offload and re-drives it. If tape software has been restarted, the MOUNT is re-issued. (We also get pages on DSNJ017)

    If you're logging VERY quickly, you could potentially blow through active log space before you realize that archival is suspended. But Db2 can't really know the process is stalled...wonder if a WAIT_FOR_ARCHIVE parameter would be effective, followed by a cancel and re-drive with Operator Message if that time is exceeded.

  • Guest
    Jun 19, 2020

    Hi Tom, we had in the past also such problen in this direction. This was the reason why we first write all archive logs on DASD. Later HSM takes them to VTS. In case VTS wont work we have some time to react. I also removed one archive side in the past to save some time and space until VTS was avail again. On the other hand when VTS wont work we also will have other problems. Then Db2 is only one part in the chain having problems. But nevertheless i was able to stop for example all development systems to keep production longer alive and stop production by hand if needed instead waiting until it fails. Idea could be a process like a allocation template switching. If VTS could not be reached for Db2 it reallocates on a defined SMS Storage configuratrion.