trying to migrate underlying vsam datasets

william giannelli

trying to migrate underlying vsam datasets

Hello,

We are trying to save DASD space. We are looking to migrate to tape underlying vsam datasets for some rarely used Db2 application objects. if referenced the vsam dataset would be free to be recalled. After a certain number of days we want to set the management class to then migrate the dataset again. Does anybody see an issue with this approach? And is there anything within Db2 that would prevent this?

thanks

Bill

Lizette Koehler

trying to migrate underlying vsam datasets
(in response to william giannelli)
We do this for development and not production.



You can run a test to ensure the application has no issue with a migrated/recalled dataset



Note: Ensure the mgmt. class does not delete the dataset if it remains migrated. For example, delete non-use after 100 days.



Also, if a migrated dataset gets deleted, DB2 will still think it is there. So the application/SQL will get a failure and you will need a method to recover the file.



For example: Any DB/TS that is deleted due to non-use for over 5 years, the DBA team either has to refresh from production or create an empty DB2 db/ts



Lizette





From: william giannelli <[login to unmask email]>
Sent: Sunday, March 10, 2019 6:26 PM
To: [login to unmask email]
Subject: [DB2-L] - trying to migrate underlying vsam datasets



Hello,

We are trying to save DASD space. We are looking to migrate to tape underlying vsam datasets for some rarely used Db2 application objects. if referenced the vsam dataset would be free to be recalled. After a certain number of days we want to set the management class to then migrate the dataset again. Does anybody see an issue with this approach? And is there anything within Db2 that would prevent this?

thanks

Bill



-----End Original Message-----

Javier Estrada Benavides

RE: trying to migrate underlying vsam datasets
(in response to Lizette Koehler)

Hello, William

  You can certainly try and test it, however, the final call is a clear "it depends" as always. If your applications can handle the waiting time for recalling your datasets, then you're free to try it, but the storage guys will have to handle the queues very carefully so that, for example, they don't delete all recall requests and create a failure to your applications that are in wait (and they will also have to plan how many drives are online for which LPARs). And quite obvious but good to mention, you wouldn't really want to try this with distributed applications with strict SLAs.

 

 

Regards,

Javier Estrada Benavides, Czech Republic / Mexico

IBM Champion for Analytics

IBM Certified System Administrator - Db2 12 for z/OS

IBM Db2 12 DBA for z/OS - 2018 (the ugly brown badge from IBM Open Badge Program)

IBM Certified System Administrator - DB2 11 for z/OS

IBM Certified Database Administrator - DB2 11 DBA for z/OS

Kirk Hampton

trying to migrate underlying vsam datasets
(in response to Lizette Koehler)
Agree totally with all of Liz's points.
A former client of mine had been doing exactly this for many years, this is
definitely not new technology. They did Production as well, but with a
long non-use period (270 days, IIRC).

The one thing I would warn about is the time period DB2 will wait on the
recall before aborting the request and returning a -904 to the client. I
believe this is may be in ZPARMs. In their Development environments, it
was not unusual for a recall to take maybe one second longer than the
time-out interval, so the developers would get "resource not available",
put in a call to the Systems group, and by the time they looked into the
situation, the dataset was in fact recalled and fully available.

Thanks,

Kirk Hampton



On Sun, Mar 10, 2019 at 8:39 PM Lizette Koehler <[login to unmask email]>
wrote:

> We do this for development and not production.
>
>
>
> You can run a test to ensure the application has no issue with a
> migrated/recalled dataset
>
>
>
> Note: Ensure the mgmt. class does not delete the dataset if it remains
> migrated. For example, delete non-use after 100 days.
>
>
>
> Also, if a migrated dataset gets deleted, DB2 will still think it is
> there. So the application/SQL will get a failure and you will need a
> method to recover the file.
>
>
>
> For example: Any DB/TS that is deleted due to non-use for over 5 years,
> the DBA team either has to refresh from production or create an empty DB2
> db/ts
>
>
>
> Lizette
>
>
>
>
>
> *From:* william giannelli <[login to unmask email]>
> *Sent:* Sunday, March 10, 2019 6:26 PM
> *To:* [login to unmask email]
> *Subject:* [DB2-L] - trying to migrate underlying vsam datasets
>
>
>
> Hello,
>
> We are trying to save DASD space. We are looking to migrate to tape
> underlying vsam datasets for some rarely used Db2 application objects. if
> referenced the vsam dataset would be free to be recalled. After a certain
> number of days we want to set the management class to then migrate the
> dataset again. Does anybody see an issue with this approach? And is there
> anything within Db2 that would prevent this?
>
> thanks
>
> Bill
>
>
> -----End Original Message-----
>
> -----End Original Message-----
>

william giannelli

RE: trying to migrate underlying vsam datasets
(in response to william giannelli)

When we are attempting to migrate the datasets we fail with a message that they are allocated to DBM1.

Any advice?

thanks

Bill

Philip Sevetson

trying to migrate underlying vsam datasets
(in response to william giannelli)
Bill,

Since they’re presumably open in DB2, you have something which is starting them, and possibly accessing them, in your subsystem. Once started, DB2 does not close a dataset until it needs to (because of getting close to the maximum number of datasets which DB2 can hold open).

If you need to migrate something, you may have to issue a -STOP DB.

From: william giannelli [mailto:[login to unmask email]
Sent: Monday, March 11, 2019 2:37 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: trying to migrate underlying vsam datasets


When we are attempting to migrate the datasets we fail with a message that they are allocated to DBM1.

Any advice?

thanks

Bill

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Kirk Hampton

trying to migrate underlying vsam datasets
(in response to Philip Sevetson)
Bill,
how many days since last use are you specifying for migrate in the SMS
config ?
If you are getting this kind of error, your SMS migration settings may be
too aggressive,
and everything is working as designed. You do not want to migrate anything
that is truly
being used by DB2. Also, you really want to exclude the Catalog /
Directory datasets (vcatname.DSNDB01.* and vcatname.DSNDB06.*) from EVER
being migrated.

Thanks,

Kirk Hampton



On Mon, Mar 11, 2019 at 1:43 PM Sevetson, Phil <[login to unmask email]> wrote:

> Bill,
>
>
>
> Since they’re presumably open in DB2, you have something which is starting
> them, and possibly accessing them, in your subsystem. Once started, DB2
> does not close a dataset until it needs to (because of getting close to the
> maximum number of datasets which DB2 can hold open).
>
>
>
> If you need to migrate something, you may have to issue a -STOP DB.
>
>
>
> *From:* william giannelli [mailto:[login to unmask email]
> *Sent:* Monday, March 11, 2019 2:37 PM
> *To:* [login to unmask email]
> *Subject:* [DB2-L] - RE: trying to migrate underlying vsam datasets
>
>
>
> When we are attempting to migrate the datasets we fail with a message that
> they are allocated to DBM1.
>
> Any advice?
>
> thanks
>
> Bill
>
>
> -----End Original Message-----
> **This e-mail, including any attachments, may be confidential, privileged,
> or otherwise legally protected. It is intended only for the addressee. If
> you received this e-mail in error or from someone who was not authorized to
> send it to you, do not disseminate, copy, or otherwise use this e-mail or
> its attachments. Please notify the sender immediately by reply e-mail and
> delete the e-mail from your system.**
> -----End Original Message-----
>

Paul Ogborne

trying to migrate underlying vsam datasets
(in response to william giannelli)
Bill,

STOP the associated TS / IS beforehand.

Regards,
Paul Ogborne.

> On 11 Mar 2019, at 18:36, william giannelli <[login to unmask email]> wrote:
>
> When we are attempting to migrate the datasets we fail with a message that they are allocated to DBM1.
>
> Any advice?
>
> thanks
>
> Bill
>
>
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> http://www.ESAIGroup.com/idug
>
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>

Philip Sevetson

trying to migrate underlying vsam datasets
(in response to william giannelli)
Bill,

One thing not previously mentioned, and please excuse me if it strikes you as too obvious. :-)

Do not attempt to take copies of the objects (DB2 COPY utility) while they are migrated. At best, this will cause a recall; at worst, the job will fail at some inconvenient time (3AM?), resulting in an oncall incident.

--Phil S.

From: william giannelli [mailto:[login to unmask email]
Sent: Sunday, March 10, 2019 9:26 PM
To: [login to unmask email]
Subject: [DB2-L] - trying to migrate underlying vsam datasets


Hello,

We are trying to save DASD space. We are looking to migrate to tape underlying vsam datasets for some rarely used Db2 application objects. if referenced the vsam dataset would be free to be recalled. After a certain number of days we want to set the management class to then migrate the dataset again. Does anybody see an issue with this approach? And is there anything within Db2 that would prevent this?

thanks

Bill

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

william giannelli

RE: trying to migrate underlying vsam datasets
(in response to Philip Sevetson)

Hello all,

Thanks for all your help and responses!

I was able to migrate one of our underlying vsam datasets after stopping the object. My next question is, aside from the object being accessed (ie read or an imagecopy), is there anything that might be specified in the system that would recall the dataset at system startup?

thanks

Bill

Paul Ogborne

trying to migrate underlying vsam datasets
(in response to william giannelli)
Hi Bill,
You could REPAIR one page to recall the dataset. Lots of other options of course.
Regards,
Paul Ogborne

> On 11 Mar 2019, at 20:45, william giannelli <[login to unmask email]> wrote:
>
> Hello all,
>
> Thanks for all your help and responses!
>
> I was able to migrate one of our underlying vsam datasets after stopping the object. My next question is, aside from the object being accessed (ie read or an imagecopy), is there anything that might be specified in the system that would recall the dataset at system startup?
>
> thanks
>
> Bill
>
>
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> http://www.ESAIGroup.com/idug
>
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>

James Campbell

trying to migrate underlying vsam datasets
(in response to william giannelli)
Nothing to stop you issuing your own HRECALL commands. With NOWAIT might be good.

I once let end users do this in a system after giving them EXECUTE authority on the VSAM
clusters.

Or you can use -ACCESS DATABASE ... MODE(OPEN) if that is what you want.

But either way, you have to run it manually, admin task scheduler or system automation,

James Campbell


On 11 Mar 2019 at 13:45, william giannelli wrote:

>
> Hello all,
> Thanks for all your help and responses!
> I was able to migrate one of our underlying vsam datasets after stopping the object. My next
> question is, aside from the object being accessed (ie read or an imagecopy), is there anything that
> might be specified in the system that would recall the dataset at system startup?
> thanks
> Bill
>


---
This email has been checked for viruses by AVG.
https://www.avg.com