You may wish to engage IBM via an SR/PMR. They may be able to identify the
issue.
However, depending on your level of z/OS there may be fixes or suggestions
1) Did you recently install any fixes to the current z/OS or upgrade to a
new z/OS?
2) Are you sharing with other LPARs.
3) By sequential - these are NON VSAM?
a) Are they GDGs
b) Are they IMS/DB2/ or other subsystem type files?
4) Did anything change in SMS recently other than the redirection of the
files?
a) Is the Dataclas the same as it was before the ACS changes?
b) how did you change the SMS Code to point to MOD54s? Did you create
a new pool? Or are these NONSMS volumes
5) Have you reset the performance statistics in the CATALOG address space,
run the job, then display the statistics to see what may have changed?
6) Have you reviewed any RMF data from the time the job ran?
7) Do you have performance tools like Tivoli Omegamon or Strobe? If so,
run it on the job and see where the time is spent.
Lizette
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Sheldon Davis
> Sent: Wednesday, February 18, 2015 11:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 with the message: INFO IBM-MAIN
