IDA019L1

[moulisea]

Hi,

when I did strobe for a long running job, it showed below section name took more than 40%

MODULE SECTION LINE PROCEDURE START % CPU TIME
NAME NAME NUMBER NAME LOC SOLO TOTAL

.VSAM IDA019L1 VSAM RECORD MANAGEMENT 41.15 43.21

can you please let me know what is this IDA019L1.

Thanks,
Mouli

 

[papadba]

Which compiler is being used on which operating system?

It appears that your process is spending this time doind something VSAM . . .

 

[moulisea]

we use z OS 1.13 and use CB2LNKB proc for compile

 

[papadba]

CB2LNKB proc for compile
This most likely the name of a PROCedure local to your system. I suspect the compiler is Enterprise COBOL 4.something . . .

Why does someont believe there is a problem?

 

[moulisea]

Enterprise COBOL for z/OS 3.4.1

 

[MarcLodge]

Hi moulisea,
IDA019L1 is one of the control module programs that is called when accessing VSAM files. If you type 'IDA019L1 VSAM' into Google, you get quite a number of hits, any of which might be pertinent to your problem. If you are not getting enough information out of the failing or slow running job, then I suspect that you are going to have to add some debugging displays and traces in order to see exactly what statement in the program that is causing the delay or hang.

From the output on Google, it seems that a number of IBM patches are out there which may apply to your system.

Marc

 

[papadba]

Thanks for the clsrification on the compiler.

As asked before:
Why does someone believe there is a problem?

Were you just doing some observations or was the reason for seeinig tis in Strobe because of a problem?

 

[moulisea]

why that is consuming 41% is the question here

If something could be done to avoid that, this job which runs for 10 hrs can be reduced.

 

[papadba]

Someone qualified will need to look at how the vsam is defined and how the code is written to accomplish this process. . .

How are alternate index entries defined / used?

How many records are in the file? How many record are "read" for this process. Often a problem is when rows are read over and over in the same process.

 

[bithead9]

Or you can try adding a BUFNI=10 and BUFDND=20 to the JCL for the VSAM dataset in question. Or code the BUFFERSPACE par on the IDCAMS define. (Using enough for 10 index and 20 data buffers). I have worked on mainframes for over 30 years and this is a great starting point to tweak the I/O processing. It could be that your VSAM dataset needs reorganization or it could be a poorly written program or a number of other things. But starting with a simple JCL change is easy. Also check your GRS enqueues/reserves while it is running or look at the Strobe report for the same. You could have lock contention or latch contention. These could show up as excessive CPU.