IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

How to cancel jobs which recalling migrated datasets


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
shankar.v

Active User


Joined: 25 Jun 2007
Posts: 196
Location: Bangalore

PostPosted: Mon Jul 30, 2012 3:03 pm
Reply with quote

Hi

Could you please let us know how to cancel jobs which recalling migrated datasets.

I have submitted multiple jobs in a particular class and there are migrated datasets used in those jobs. Those jobs started recalling migrated datasets and running for long time & other users jobs waiting on queue as initiators allocated to that class are occupied by those jobs. I have tried cancelling those jobs, but those jobs are getting cancelled after recalling the datasets.

Could you please let me know is there anyway to cancel the job which is doing recalling the migrated datasets?.
Back to top
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 199
Location: UK

PostPosted: Mon Jul 30, 2012 3:20 pm
Reply with quote

You cannot cancel the job until the recall completes or fails.

You can however cancel the recall, which will then allow the job to cancel. There are various permutations of the cancel command in DFHSM - you can cancel specific recall tasks, all recalls for a particular dataset or all recalls for a particular user.

Look up the CANCEL command in the DFHSM manual to find the best option for your situation.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Jul 30, 2012 3:59 pm
Reply with quote

shankar.v,

now that you know that in a batch job, recalling a migrated ds
can take a while.

Quote:
I have submitted multiple jobs in a particular class

and were appropriately clever enough to have different job names,
so that they would execute concurrently.



good for you.

when you know,
and it should be easy to determine, although it does take a few seconds of your precious time,
simply have one job that contains 1 step,
an iebfr14 with all the ds that you will be using in your jobs,
have disp=shr.
that way you only have one job clogging the initiator
instead of several.

now, the only reason that you posted,
is because you got caught submitting several jobs in such a way
that they all went active.
another user noted that you have multiple jobs that are all waiting on migration
and he can not get his jobs to run.

it only takes a few seconds to view and capture all dd cards for dsn's that are not disp=new,
and build your 1 step job to recall all datasets that you will be using that day.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Mon Jul 30, 2012 7:19 pm
Reply with quote

Hello,

Quote:
...build your 1 step job to recall all datasets that you will be using that day.
Several of my sites have rules that will re-migrate datasets (based on dataclas and size) if they have not been used within an hour.

We found that using the br14 to recall datasets for the job worked well.
Back to top
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1691
Location: Tiruppur, India

PostPosted: Mon Jul 30, 2012 7:53 pm
Reply with quote

Quote:
rules that will re-migrate datasets (based on dataclas and size)

Hello D,
Just a query. Can datasets be made to be migrated based on data class as well? I thought dataset migration setup is setup in management class.
Regards,
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Mon Jul 30, 2012 8:02 pm
Reply with quote

Hi Vasanth,

Could be - what i hear is "class" and size. . . I'm not sure if it is management class or dataclas or even both. That is for the storage folks icon_smile.gif

d
Back to top
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1691
Location: Tiruppur, India

PostPosted: Mon Jul 30, 2012 8:08 pm
Reply with quote

Oh ok :-)
I used to remember the classes this way,

data class - how it will look like(the dataset attributes)
management class - what will happen to it(migration,backup & retention rules)
storage class - how it will perform(performance rules)
storage group - where it will go(the volume pool in which it will reside)

P.S - apologies for hijacking the topic :S
Back to top
View user's profile Send private message
Grant Goodale

New User


Joined: 13 Nov 2010
Posts: 55
Location: Brampton, Ontario, Canada

PostPosted: Mon Jul 30, 2012 11:33 pm
Reply with quote

Putting in DD statements to do the recall could be very inefficient. It is better to run a TSO in batch job that includes HRECALL commands for the desired datasets. That job will complete quickly which will free up an initiator. The best part of this is that HSM then organizes the recalls so that the number of volume mounts is minimized. Even if you are using a silo library, that still reduces run times.

FWIW

- Grant
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Mon Jul 30, 2012 11:36 pm
Reply with quote

Hello,

Yup, i believe using HRECALL is a better option - as long as the system allows developers to issue HRECALL. Many of my clients have restricted this . . . .
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Tue Jul 31, 2012 1:21 am
Reply with quote

If HRECALL is indeed used, TSO should probably be run as a step in the job using the recalled data sets, and should only recall those data sets that job will actually use. It may well be that the restrictions on the use of HRECALL at some site originated with a developer saying, "Well, I might want one of these 10,000 data sets today, so to prevent a thirty-second delay in my job later I'll recall them all..."
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 541
Location: London

PostPosted: Wed Aug 08, 2012 7:43 pm
Reply with quote

You can cancel active recalls these days using the HSEND CANCEL TCB command but it is restricted to authorised Storage personel (and hopefully knowledgable ones). You have to do the HSEND Q ACT(TCB) first to find the 'correct tcb' address of the task you want to end.

Another option is to prioritise the recalls using the HSEND ALTERPRI DSN(name) HIGH, but again it is a restricted option.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Aug 08, 2012 8:05 pm
Reply with quote

one thing that would solve the problem:

Quote:
I have submitted multiple jobs in a particular class


do not do that!

the solution is not:
  • a better way to anticipate usage of recalled dsns
  • acquire authority to cancel jobs
  • generally go about life without taking into account the ramifications of your actions
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts List of quiesced jobs JCL & VSAM 3
No new posts PL/I, VB Datasets and the RDW PL/I & Assembler 4
No new posts how to get list of all VSAM/non-VSAM ... JCL & VSAM 13
No new posts define 1 DCB parms for multiple outpu... JCL & VSAM 9
No new posts Negative dependency between jobs in m... COBOL Programming 12
Search our Forums:

Back to Top