How to copy large dataset from TAPE to DASD memory?

Gopalakrishnan V · Posted: Mon May 05, 2014 5:01 pm

Hi,

I need to copy a large dataset from TAPE to DASD. I am trying all possible methods which i read from old posts. Previously I was getting ABEND SB37 and I have increased the cylinders. But now I am facing ABEND S322 time out. I gave TIME=MAXIMUM but still I am getting the time out abend. Please find my JCL details below and provide your suggestions,

Bill Woodger · Posted: Mon May 05, 2014 5:17 pm

Can you post the sysout from the step, please? Is TIME=MAXIMUM something at your site? TIME=1440 or TIME=UNLIMITED are standard, but it would seem odd that you have a tape copy which runs out of CPU time. Are you running in an initiator which has its own time limit which you cannot override?

Robert Sample · Posted: Mon May 05, 2014 5:52 pm

It is unusual for a tape copy to run out of time, unless as Bill indicated the job class you are running in has a time limit.

You need to work with your site support group as they know your environment and how to achieve what you want to do. We on this forum do not work at your site and have no idea about its limitations and specifics.

steve-myers · Posted: Mon May 05, 2014 6:44 pm

IEBGENER is hardly the most CPU efficient method to copy data, but the problem seems rather odd. Most of us are too lazy to use something that is more CPU efficient even if we are aware of the issue. Some other agent hiding behind the scenes may be chewing up the CPU, such as an agent to decrypt data coming from the tape.

Mr. Woodger's thought about an "initiator time limit" is almost on the spot, but slightly misplaced. "Standard" MVS usually imposes what amounts to a step time limit based on job class. All of us old dinosaurs have been zapped by this at one time or another. Most sites set this time limit rather low, but it is trivial to override this step time limit; we just forget to do it. Just code TIME=nnn on the EXEC statement, where the nnn is greater than the installation imposed time limit. Look for the

IEF374I STEP/xx /STOP 2014124.2201 CPU 0MIN 58.15SEC SRB 0MIN 04.13S

message in the JESYSMSG data. This step used almost 1 minute of CPU time. If the step time limit is one minute AND the step required a couple more seconds CPU time the step would have failed even if the job time limit is adequate.

You should be able to determine your installation's default. These instructions are for JES2; JES3 would be different.

Determine the job class used for the job. Look for the $HASP373 message in the JESMSGLG data set for the job. This message has CLASS x in it.
Enter the $DJOBCLASS(x) command. If you are allowed to enter this command you should see a long response in message $HASP837; the default step limit is near the beginning as TIME=(nnnn,nn).
If you can't use the $DJOBCLASS command, you might be able to find the default in the JES2 initialization parameters. This is a little more difficult, and it might be hidden in a RACF protected data set anyway.
You can probably make a good guess by using the time in the IEF374I message if worse comes to worse.

dick scherrer · Posted: Mon May 05, 2014 8:33 pm

Hello,

Suggest you speak with your storage management and learn if there is a preferred unit and dataclas.

Change the execution to use your sort product to do the copy. This will use far less cpu resource and will execute considerable faster.

Gopalakrishnan V · Posted: Tue May 06, 2014 7:02 pm

Hi All,

Thank you all for your suggestions. I had given TIME=1440 in step level and got authority issue. So i gave TIME=1400 and job completed successfully.

Bill Woodger · Posted: Tue May 06, 2014 7:10 pm

Please don't ignore Dick's advice in the same way you've ignored requests for more information.

dick scherrer · Posted: Tue May 06, 2014 7:12 pm

Hello,

You should NOT use time=1440. Period.

Well managed organizations will flush these when they are submitted.

If a simple copy takes that much resource, there is something wrong. Possibly the selection of iebgener as the copy program.

How many records are being copied? Why is something this large being copied to dasd?