JCL ERROR as file got migrated

kumarreddyuppaluru · New User Joined: 17 Mar 2008 Posts: 8 Location: Bangalore

Hi,

In our project , jobs are scheduled through control-m. i got a abend recently. It is giving JCL ERROR , UNEXPECTED CATALOG LOCATE PROCESSING ERROR - RETURN CODE

when i checked the dataset, i observed that got migrated. The same kind of problem came with other job also. I restarted the job and it went fine.

But my doubt is when we submit the job, JCL is able to recall the file, But it is not able to recall when it is submitted through control-m.

Could some one please tell me how i can eliminate this in future.

The following is info abt the dataset

General Data Current Allocation
Management class . . : MCPRDDEF Allocated tracks . : 1
Storage class . . . : SCMASTER Allocated extents . : 1
Volume serial . . . : SMAL7P
Device type . . . . : 3390
Data class . . . . . : DCHSM Current Utilization
Organization . . . : PS Used tracks . . . . : 0
Record format . . . : FB Used extents . . . : 0
Record length . . . : 80
Block size . . . . : 9040
1st extent tracks . : 1
Secondary tracks . : 60
Data set name type : SMS Compressible : NO

Creation date . . . : 2004/06/26 Referenced date . . : 2009/06/16
Expiration date . . : ***None***

enrico-sorichetti · Posted: Wed Jun 17, 2009 12:25 am

not enough info,
what does Your storage support group say

kumarreddyuppaluru · New User Joined: 17 Mar 2008 Posts: 8 Location: Bangalore

Sorry ,

Return code is 38

expat · Posted: Wed Jun 17, 2009 11:28 am

Yes, has happened before. The program opens the file which is currently being recalled, and then throws a wobbly.

You need to ensure that any migrated files are recalled before the batch job is processed.

gcicchet · Posted: Wed Jun 17, 2009 11:46 am

Hi,

I'm sure it has nothing to do with job being submitted through Control-M.

Gerry

Anuj Dhawan · Posted: Wed Jun 17, 2009 12:45 pm

kumarreddyuppaluru · New User Joined: 17 Mar 2008 Posts: 8 Location: Bangalore

Yes Anuj, i got description IGD04001I.

For this is there any possibility to do on my own? is it the only way (contact Storage support guys).

Anuj Dhawan · Posted: Thu Jun 18, 2009 10:43 am

If this is to do with Production runs -- strongly suggest you get in touch with Storage support or if it's a "test-region" thing you need to ensure that any migrated files are recalled before the batch job is processed, as Expat has suggested.

gcicchet · Posted: Thu Jun 18, 2009 10:50 am

Hi,

just add an IEFBR14 step to recall the files before they are needed.

Gerry

Anuj Dhawan · Posted: Thu Jun 18, 2009 11:34 am

Hi Expat, Gerry,

I'm not a storage guy so curious-- how in the production one will ensure such things, I mean "recalling migrated files before the batch job is processed" -- adding IEFBR14 is how good, what if every jobs has such DSNs to recall? What about the I-O time for such jobs?

expat · Posted: Thu Jun 18, 2009 11:54 am

That's where a storage team that knows what happens is important. I always produce reports of datasets recalled by production jobs, and go talk to the JCL monkeys about the job schedules. If it is that the ILM has auto migrated the data, then the dataset would be allocated a different MGMTCLAS to retain it on DASD, depending on size.

Of course if it's one of the JCLM's that has migrated it manually, he usually gets informed to keep his grimy little mits off of my HSM.

For very large datasets, usually for ME and QE processing it's an automated recall one or two days before the scheduled run into a specific temporary storage group for the large stuff.

All so very easily controlled by correct setup of the ACS routines.

Anuj Dhawan · Posted: Thu Jun 18, 2009 12:18 pm