How to cancel jobs which recalling migrated datasets

shankar.v · Posted: Mon Jul 30, 2012 3:03 pm

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?.

David Robinson · Active User Joined: 21 Dec 2011 Posts: 199 Location: UK

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.

dbzTHEdinosauer · Posted: Mon Jul 30, 2012 3:59 pm

shankar.v,

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

dick scherrer · Posted: Mon Jul 30, 2012 7:19 pm

Hello,

vasanthz · Posted: Mon Jul 30, 2012 7:53 pm

dick scherrer · Posted: Mon Jul 30, 2012 8:02 pm

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

d

vasanthz · Posted: Mon Jul 30, 2012 8:08 pm

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

Grant Goodale · Posted: Mon Jul 30, 2012 11:33 pm

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

dick scherrer · Posted: Mon Jul 30, 2012 11:36 pm

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 . . . .

Akatsukami · Posted: Tue Jul 31, 2012 1:21 am

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..."

Pete Wilson · Posted: Wed Aug 08, 2012 7:43 pm

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.

dbzTHEdinosauer · Posted: Wed Aug 08, 2012 8:05 pm

one thing that would solve the problem: