Performance issue with Tape dataset.

magesh23586 · Posted: Fri Apr 12, 2013 1:59 pm

we have a db2 job which basically takes image copy to a tape dataset which is consuming more time , please advice on optimizing the same.

JCL

enrico-sorichetti · Posted: Fri Apr 12, 2013 2:04 pm

magesh23586 · Posted: Fri Apr 12, 2013 2:12 pm

Job takes 23 Minutes to just Mount, after mounting the step was completed in 5 minutes.
Please check time from 20.55.50 - 21.18.53 .

enrico-sorichetti · Posted: Fri Apr 12, 2013 2:16 pm

it should not take too much ingenuity to understand that the way the job is written does not influence the availability of the needed tape units...

whining on a forum will not make the tape units available sooner

why not speak to Your operations support instead ?

magesh23586 · Posted: Fri Apr 12, 2013 2:25 pm

Sure, Will definetly talk with operation team.

Is there any paramter changes we can do to help the job to mount the dataset effectively/quickly ?

Please advice

expat · Posted: Fri Apr 12, 2013 3:21 pm

How can you mount a tape when there are no tape drives available ???

Do you not understand that the problem is your job is waiting for tape drives to become available to mount the output tapes onto.

Anuj Dhawan · Posted: Fri Apr 12, 2013 5:45 pm

Nic Clouston · Posted: Fri Apr 12, 2013 5:56 pm

And, once a valid scratch tape was mounted the step took just over 1 minute wall time.

magesh23586 · Posted: Fri Apr 12, 2013 6:11 pm

Anuj,

I understand it is not consuming CPU and it consuming just time.

Expat,

I understand the job is waiting for the tape drive availability.
I just want know, is there any parameter involved, which will give special priority to my job and make sure the tape drive is available for me at the first time of request. Because after 20 minutes the tape drive was available and the tape is mounted. I have enclosed only one step, there are 20 steps involved, and each takes 20 to 30 minutes. The job take approximately 9 hours.

Regards,
Magesh

enrico-sorichetti · Posted: Fri Apr 12, 2013 6:14 pm

if a tape unit is not available, no jcl or whatsoever parameter will make one available for You full stop

Gary Jacek · Posted: Fri Apr 12, 2013 9:50 pm

Perhaps the esoteric "CART" refers to hardware that requires a manual tape mount. That would mean that every time your jobstep changes, some poor console operator must get out of their chair, walk across an acre/hectare of raised floor, find a scratch tape, and mount it in the drive.

// UNIT=(CART,,DEFER),

You should ask your operations support team what tape esoterics might be more appropriate to your needs. They may be able to offer you tape that resides in a silo or ATL that is mounted for you by a robot, or they may be able to offer you an esoteric that gives you access to "virtual tape". That is to say, direct write to DASD which is then archived later to a pool of tapes that back up the virtual tape subsystem.

This list of esoterics can only be provided by your onsite staff.

Good luck.

dick scherrer · Posted: Fri Apr 12, 2013 11:56 pm

Hello,

Suggest you work with your Operations or Scheduling people to determine why this job is being run when there is no tape device available.

How many tape drives of this type are available on the system?

What about writing the output to dasd and eliminate the wait for the tape?

magesh23586 · Posted: Thu May 02, 2013 5:35 pm

Thanks for the kind advice,

We have decided to load the data into to DASD, and then move it to tape later using another job, which will be scheduled after batch.

Regards,
Magesh

dick scherrer · Posted: Thu May 02, 2013 6:39 pm

Thank you for letting us know you have a direction.

d

Pete Wilson · Posted: Thu May 16, 2013 1:13 pm

What is the point of writing to DASD and then copying that to TAPE, you've just triplicated your data. If you write to DASD then that dataset should be able to be migrated by DFHSM or equivalent which will move that dataset to tape for you, efficiently. Talk to your Storage team to ensure the file you're creating has the correct Dataclas (to compress the file), and the correct Mgmtclas (to ensure it gets migrated). Also, specify BLKSIZE=0 so the dataset automatically gets the right blksize regardless of the media its written to.

dick scherrer · Posted: Thu May 16, 2013 8:32 pm

Yup, agreed

d

Gary Jacek · Posted: Fri May 17, 2013 12:35 am

If you have the right permissions, you can write your dataset to disk and then execute a jobstep to ask HSM to send the dataset to ML2. In most shops ML2 is on tape and HSM puts as many datasets as will fit, onto that tape. So very efficient for tape management.

//*
//SENDML2 EXEC PGM=IKJEFT01,DYNAMNBR=128,REGION=1024K
//*
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//*
//SYSTSIN DD *
HMIG 'your.disk.dataset' ML2
/*
//*

expat · Posted: Fri May 17, 2013 11:52 am

I think that Interval Migration would be an easier way to go using DFHSM.

No need to worry about the correct authorisations, no need to update control statement members when changes are made. Just let HSM do its stuff regardless.