IBM Mainframe Forum

Hi


< Please correct me wherever i am wrong >

As far as i know the EXCP count indicates the number of I-O operation executed for your program. So if anyhow we could decrease the EXCP count then it is possible to save the time for execution. The EXCP count increases by one when the system fetch one block of data from hard disk(DASD) to system memory. If we increases the block size then then it will cover more number of bytes in one block and hence require less EXCP count. Could you please clarify my concept about EXCP count and its relation with block size and BUFNO and is it possible that i was thinking???


Thanks in Advance

You are focusing on one aspect of performance, possibly to the detriment of the overall job. Yes, a larger block size can reduce EXCP count but these days SMS-managed data sets are already at an optimal block size, along with data sets created with BLKSIZE=0 to let the system choose it. Furthermore, the amount of time to transfer the data from disk to memory goes up as the block size goes up, and the amount of memory required to store the block of data goes up so you may run into other issues; some sites, for example, limit the memory in certain job classes so you may have to change your job class when you increase the block size. BUFNO indicates how many buffers should be used -- in general, the more the better (up to a point); at least 30 buffers will almost always help over the QSAM default of 5 and I've seen cases where up to 250 buffers continued to improve performance.

One key note about performance to remember: jobs are either CPU-bound or I/O-bound. If your job is CPU-bound, that means it needs more CPU to reduce the job elapsed time, so no changes to block size or BUFNO will impact the elapsed time (even though EXCP count may go down).

These users thanked the author Robert Sample for the post (total 2):

ramkumar1992sp (Fri Apr 28, 2017 12:32 am) • krishnaraj6eee (Thu Apr 27, 2017 11:31 am)

I found this in the 2015 Hot Topics Share presentation :

z/OS 2.2: New zFS Support for EXCP Counts
 z/OS 2.1 and Prior: zFS updates EXCP counts for every cache page touched by
the current operation on the user task
̶ Number of cached pages really touched not consistent even for single system cases
̶ In directory operations, pages touched is determined by current layout of the directory and
what was cached in memory
• Also if forwarding directory operations to owners, the client did not touch pages so if some directory
operations were run on a client instead of an owner the EXCP counts may be way off
 In z/OS 2.2 changes are made:
© Copyright IBM Corporation 2015
̶ File reads and writes operate the same - number of cached pages touched because
clients do direct file IO so this is an exact count of user cache pages touched
̶ For directory updates and reads, zFS will determine the minimum number of meta cache
pages required for the operation and use that number
• Ensures client and owner are consistent and the accounting is simple and reasonably accurate

So if your COBOL code is accessing a zFS (Unix) file, and you're not on z/OS 2.2, the EXCP counts may have no relationship to actual I/O counts.

Programs fetching data from DB2 seem to behave in a similar fashion. I haven't done any research into it, but they will run a long time without any change to EXCP count.

<Sorry for late reply>

Thanks all of you for giving good advises

Robert Sample wrote:... the EXCP counts may have no relationship to actual I/O counts.

Sorry about returning to this at this late date, but ...

The reality is the EXCP count as recorded for accounting has nothing to do with the real I/O count. This has been true since the advent of Data Facility Product in the late 1970s or early 1980s - I don't remember exactly. DFP would not have achieved its real performance improvement for SAM I/O if it did not combine several physical records into one real I/O. DFP restored EXCP count to its traditional meaning: one EXCP for one physical record. But it is a lie, and has been a lie for more than 30 years.

This is even more true with caching I/O controllers and modern DASD. The real I/O - and it happens in the micro code in the controller and MVS has no knowledge of what the controller is really doing - is in track units and the controller is simulating traditional count - key - data I/O.

The reality is the EXCP count as recorded for accounting has nothing to do with the real I/O count. This has been true since the advent of Data Facility Product in the late 1970s or early 1980s - I don't remember exactly. DFP would not have achieved its real performance improvement for SAM I/O if it did not combine several physical records into one real I/O. DFP restored EXCP count to its traditional meaning: one EXCP for one physical record. But it is a lie, and has been a lie for more than 30 years.

My whole life has been a lie. (O_o)

I thought excp calls were done for each IO.

vasanthz wrote:... I thought excp calls were done for each IO.

Yes, but it's not so hard to fake the count, and it is not so hard for a single EXCP to read more than one physical record.

Actually, now that I've jogged my memory a bit, ... the SAM performance improvement goes back to the SAM-E product. SAM-E as it was originally released had a terrible reputation and many shops would not install it. After a bit SAM-E and several other products including HSM and DSS and other data management related products were combined into what we now know as DFSMS, and we were forced into using DFSMS, sometimes kicking and screaming because it incorporated SAM-E, which by this time was actually pretty stable.

I thought excp calls were done for each IO.

Live and learn. Live and learn.

Considering the discrepancy between memory access time and I/O time, IBM (along with all other vendors) has worked for many years to reduce I/O as much as possible to keep the CPU processing data. Even many years ago, multiple physical blocks could be read via chained CCW so EXCP and I/O haven't had a direct relationship for a LONG time!