Tape file read issue

baljinders · New User Joined: 21 Aug 2006 Posts: 72

Hi,

I am trying to extract data from a monthly tape file (its a GDG) . Its a multi volume dataset (70 volumes used to store the data) and has close to 140 millions records. The daily version of the file has around 7 million records and its on DASD. The job is running fine for the daily version but getting timed out while running with the monthly file. For the first time , it ran for 4 hours and mounting 33 volumes before it got timed out. In the next run i gave the time parameter in the job card and it ran for close to 7 hours and got operator cancelled while it was mounting the 50th voulme. How can i overcome this issue ?

The tape file has lrecl= 3000, RECFM=VBS

My output file is a fixed format PS file with a LRECL=500

enrico-sorichetti · Posted: Sat May 01, 2010 7:19 pm

the best place to ask for solving this issue is certainly Your operations support!
after all the job got operator cancelled so nothing to expect from a forum

baljinders · New User Joined: 21 Aug 2006 Posts: 72

Thanks Ernico, I'll get in touch with the operation support.

Ronald Burr · Posted: Sat May 01, 2010 8:02 pm

You say that the first run "timed out" after 4 hours ( 33 mounts ). What do you mean by "timed out"? Did the job exceed the "clock time" established for the job class? the "cpu time" established for the job class? the TIME coded in the Job Card?
You didn't say WHY the operator cancelled the job in the second run. Was it cancelled for running too long? If so, who made that determination? Was it cancelled because there was a need to quiesce the mainframe for stand-alone maintenance? A re-IPL?

As an aside, with a ( variable ) LRECL of only 3000, why is the file defined to use SPANNED records? I ask that because with UN-spanned records it might be possible to run the process in segments ( if there is no inter-record logic being applied ) - e.g. reels 1-x in one run, reels x+1 thru y in a second run, reels y+1 thru z in a third run, etc. With SPANNED records this is not an option. That could minimize the impact of any operator cancel that occurs while waiting for a mount ( it would take some intervention if the job was cancelled or abended while processing a reel, since you would have to delete any output records associated with the current reel ).

A second question is: how many tape drives are allocated to the input file? If you are only specifying UNIT=TAPE, for example, you are "wasting" time for mounting between each volume. If you specified UNIT=(TAPE,2) then the "next" reel could be mounted while the "current" reel is being processed ( ping-pong'ing drives ), thus reducing any mount time impact on the job considerably.

A third question is: how many I/O buffers are allocated to the input file? The COBOL default is 5, but if you can increase that BUFNO then processing time might be improved.

baljinders · New User Joined: 21 Aug 2006 Posts: 72

Thanks every1,

The issue got resolved. I ran the job with a different job class and it ran fine.

Ronald,

The job got a S322 when it abended the first time. So re -ran the job by including the time parameter in the job car.

Second time, it got s222, which i thougth was operator cancelllation. But was ended by the system. so i changed the job class and re-ran.

Also,
The file was a prod file and it was defined that way (i.e with RECFM=VBS )
and no I/O buffer was mentioned in the JCL for the file to improve processing time.

Thanks again for your effort to explain the things i needed to check to get the resolution for the issue and use them to avoid any similar issues in future.

Robert Sample · Posted: Sun May 02, 2010 6:51 pm

An S322 occurs when the job exceeds the time limit. However, increasing the time on the JOB card may have no impact since sites can impose limits by job class -- which is why you absolutely must contact your site support group in this type of situation; nobody outside your site can assist you in getting the parameter(s) needed.

An S222 occurs when the job is canceled, by the console operator or by an automated process acting as a console operator. If done by a console operator, you must contact your site support group to find out why it was canceled. If done by an automated process, it is typically done because your job violated a site restriction - -and again you need to find out from your site support group how to keep this from happening.

baljinders · New User Joined: 21 Aug 2006 Posts: 72

Thanks a ton Robert,

You gave me a clear picture on how to tackle these two abends.

Thanks again