Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

High Volume recall/rename/migrate

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
kplkpl4

New User


Joined: 14 Sep 2006
Posts: 4
Location: Tampa

PostPosted: Tue Jul 13, 2010 10:10 pm    Post subject: Reply to: Info on DASD
Reply with quote

I have a situation with DASD in terms of mass recall and migrate after.
We have 774,000 Datasets we need to recall and alter the DSN name. Then we will have to migrate the DSN.

Does anyone have a job to recall and migrate DSN? icon_question.gif
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8002
Location: Bellevue, IA

PostPosted: Tue Jul 13, 2010 10:15 pm    Post subject:
Reply with quote

Contact your site support group.

If you attempt to recall 774,000 data sets you probably don't have enough disk space available to do this; you could cause real problems with your production workload if you attempt this.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Jul 13, 2010 10:58 pm    Post subject:
Reply with quote

Hello,

Do not randomly post replies/questions to unrelated topics. . . All this does is create confusion and clutter.

Do not attempt to recall 774,000 files unless the storage management group has already set up separate dasd and a storage class.

Indeed, anything like this should be done by the storage management people (or by their direction).

If you charge ahead and cause space problems, look for really unhappy people to pay a visit. . .
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Wed Jul 14, 2010 11:25 am    Post subject:
Reply with quote

The only time that I have had to do something similar, migrate from another product to HSM, it was a nightmare. With HSM taking care of the new datasets it was left to migrate existing ones to HSM.

For the sake of efficiency, because this project took about 5 months to complete, I started with the datasets with the longest retention. You will need to cross reference the SMS management class against the creation or last referenced date to find out the expected expiry date. By the time I was halfway through, a lot of the datasets with lower retentions were starting to expiry naturally.

The procedure was to recall, backup and migrate to HSM. It will be much better to do this in small batches. I would typically process 300 recalls, followed by 300 HSM backups, and then 300 migrations to HSM.

And please do ensure that you do take HSM backups if you change the name as SMS / HSM will now register (assuming that your site does any HSM housekeeping) that the original datasets are no longer, and will start the expiry process for them.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 440
Location: London

PostPosted: Wed Jul 14, 2010 1:40 pm    Post subject:
Reply with quote

My first question would be why you have to do this?

I would suggest you make sure that it is actually necessary and of some real benefit. I find that all to often you'll be asked to do something where on further analysis it is actually a pointless exercise based on someones inaccurate or incomplete knowledge. You might point out just how costly it will be in terms of CPU cycles (DFHSM is hungry), man hours, and risk to normal operations while going through the process due to space issues and contention for Tape units etc. Dealing with this number of files also increases risk of 'losing' some on the way.

If it is to just force naming standard compliance for example, then it's probably less expensive and less hassle to deal with them as an exception and allow them to die a natural death as they expire, and perhaps start with the new standard going forward from a fixed point for new datasets.

One option that may be worth exploring is use of ABARS which means you can avoid the recalls because it reads directly from ML1 DASD or ML2 TAPE and creates a TAPE backup. This can be restored to the same or different Sysplex, so you may be able to go through the rename process on a test plex and then bring the data back. At least this can be done while leaving the original data intact and once happy you have all the newnamed versions in order, just delete the original migrated versions. (careful with that, I think DFHSM has an issue with >39000 deletes being issued in one go). Not sure if it's still the case but it used to be that ABARS would always restore migrated data to ML1 only, so that would need consideration. I haven't used ABARS for a long time, so it may even be possible now to restore to newnames which would save further steps.
Back to top
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Wed Jul 14, 2010 3:52 pm    Post subject:
Reply with quote

I want to sound dumb but the way question is posed, would like to ask, are you - kplkpl4, a storage-admin?
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Wed Jul 14, 2010 4:01 pm    Post subject:
Reply with quote

Anuj Dhawan wrote:
I want to sound dumb
Oh Anuj, that just begs some grief and abuse from your fellow forum members icon_lol.gif
Back to top
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Wed Jul 14, 2010 4:09 pm    Post subject:
Reply with quote

LOL - that was a deliberate effort to get united with my lost friends and voila...it worked! icon_biggrin.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Storing huge volume of data, compare ... Pradeep K M All Other Mainframe Topics 3 Mon Jan 16, 2017 5:08 pm
No new posts ESQA overflow - high ECSA utilization vasanthz All Other Mainframe Topics 1 Thu Dec 29, 2016 7:06 am
No new posts High CPU consumption Job using IAM fi... aswinir JCL & VSAM 15 Thu Dec 01, 2016 8:28 pm
No new posts Error during restore rename archanamuthukrishnan All Other Mainframe Topics 2 Fri Oct 14, 2016 3:30 pm
No new posts COBOL DB2 - CALL statement - high CPU... TS70363 DB2 15 Sun Sep 11, 2016 6:07 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us