I had this situation once when I was sharing a catalog between two LPARs. The catalogue were large and were being updated by both systems.
It turn out that when a update from system A is done to the catalog, buffers are invalidated on system B. When system B need to inquire on a dataset, all the required buffers need to be re-read. If system A and B keep invalidating each other's buffers, high CPU and I/O are required to protect the integrity of the catalog. Just a thought from my experience. Chip > On Feb 22, 2015, at 16:20, Scott Ford <idfzos...@gmail.com> wrote: > > Sheldon, > > His logic is not clear to me .....can you detail a tad more .. > > Regards, > Scott > >> On Sunday, February 22, 2015, Sheldon Davis <sda...@isracard.co.il> wrote: >> >> I have managed to recreate the problem. I will open a PMR and I will check >> with the developer why he is doing what he is. >> A cobol program reads input and then opens file (disp=mod) writes record >> and then closes file (50k times) >> >> The following are the results of my tests: >> >> Open file write 50k records close file - >> file size 30 tracks less than a second CPU >> 50k times on a non extended file open write close - file >> size 600 tracks 3 minutes CPU >> 50k times on an extended file open write close - >> file size 23000 tracks 8 minutes CPU (catalog address space doing high i/o >> on vvds of disk being written to >> >> >> >> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU >> <javascript:;>] >>> On Behalf Of Sheldon Davis >>> Sent: Wednesday, February 18, 2015 11:45 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU <javascript:;> >>> Subject: High i/o rate and CPU usage by catalog after converting a set >>> of >> files >>> to extended and placing them on model 54's >>> >>> Hi >>> I am out of ideas. >>> We converted a set of sequential files to be extended and changed the >>> ACS routine to put the files on model 54's The following is what >> happened: >>> >>> 1. Jobs that allocated the files took more CPU and ran much longer. >>> 2. The catalog address space used about four times more CPU than usual >>> and did a huge amount of I/O on the disks that the batch job used to >>> allocate >> and >>> update the files. >>> >>> Thanks for any input >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, send email >> to lists...@listserv.ua.edu <javascript:;> with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu <javascript:;> with the message: >> INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
