So at times of peak CPU, you need to "share" the CPU to provide better CICS response
times. Use "SET SHARE vsebatch REL 100 ABS 30% LIMITSOFT". Large shares will NOT do what
you think or want.
This command lets the batch use default share, but caps it at 30% CPU unless there are no
other users. If your CICS interactive and your batch are in the same server, then you
need to prioritize within VSE.
Horlick, Michael wrote:
Cross-posted to both VMESA-L and VSE-L mailing lists
Greetings,
We have just converted the last of our 5 VSE machines to z/VSE 4.1.0
(from VSE/ESA 2.6.1) and are experiencing performance issues. My peak
times are 98-100% utilization and people are complaining about poor
response times.
I don't know whether it's because I am using CICS data tables more now
or because of the additional CPU utilization for z/VSE.
Anyways, one question I have is the usage of the SET SHARE.
I have been using the 'SHARE ABSOLUTE' directory control statement for
each of my VSE machines (giving say 38% to one machine, giving 29% to
another,etc...) with maximum share nolimit.
The problems seem to occur when batch jobs are run in these
predominately CICS/TS systems.
I was wondering if maybe a SET SHARE RELATIVE technique would be more
effective and what you do in prioritizing virtual machines within the
physical machine?
Thanks,
Mike
