Run Time Stats -
START TIME 03:25:47.35
STOP TIME 05:06:44.87
ELAP. TIME 01:40:57.52
VIRT SYS USED 620K
VIRT CORE USED 1,032K
We are totally unaware of the reason for this difference. Hence, we contacted our Storage team who came up with the below explanation -
Quote:
The JOB1 normally runs around 3-4AM. Today it ran at around 5:45AM. Due to other workloads in the system at that time, the sort step could not use the virtual storage that it normally has available when it runs earlier.
Is there any way to avoid this type of unpredictable run time issue because it impacts the file delivery to the users at a wide range.
--
Thanks,
Vidhya
"If you have knowledge, let others light their candles with it. "
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
It may well be "resources" more generally rather than unavailable virtual storage per se. If there is heavy CPU/IO use later in the morning, then your job is going to "elapse" for longer. Talk to your "Production Control" about scheduling, priorities, etc, to keep it out of the heavier-load time.
This job cannot be scheduled to run around 3-4AM because it needs to wait for its predecessor jobs for input. Not all the days, the stream gets delayed. Incase of huge input volume or delayed predecessor jobs, this job is getting delayed.
Already the job is kick started late and in addition to it, this Virtual Storage issue contributes additional elapsed time which further delays the completion of the job stream impacting the file delivery time.
--
Thanks,
Vidhya
"If you have knowledge, let others light their candles with it. "
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I'm not so sure it can be just a lack of "virtual storage".
A lack of any resource you require will increase the time the job takes to run. If there is little free CPU time for your priority, that will slow you down. If little free IO capacity for your priority, that will slow you down. The lack of either of these is going to tend to indicate a lack of available virtual storage (if lots of other things are "doing something" then they have to have somewhere to do it).
You have the same problem everyone has. Availability of resources. If your job slips into a period of heavier use, then it will run for longer. Talk to your "Production Control" people. If your job is more important, in relative terms, than some of the others, they may be able to help you out.
Review your system for performance. Maybe you'll find something there.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Quote:
Is there any way to avoid this type of unpredictable run time issue because it impacts the file delivery to the users at a wide range.
Absolutely not. The elapsed time a job takes is a function not only of what resources the job itself needs, but also a function of a wide variety of system factors -- such as number of jobs, the amount of CPU those jobs needs, the amount of I/O those jobs are doing, whether or not the I/O being done hits the same disks and channels as other jobs, etc, etc, etc.
Bottom line: there is no way to remove variations in elapsed time on a z/OS system unless you dedicate one machine to running one job.
As bill suggested, talk to your 'production control' people to prioritize your job so that your job don't have to worry about other jobs being tied to CPU and IO time.
In most of the shops using the ELAP parameter is strictly prohibitied as it delays other jobs/process.
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Vidhya Kalyanasundaram wrote:
Thank you. I ll try using that ELAP option.
If you are Application developer, suggest, don't try such things at home. Get in contact with your SyncSort representative and the Storage admins and decide the approach. Parameters like ELAP are installation dependent and must be used with the help of site-support group.
You should have noticed the small difference in the two runs
Quote:
WER418I DATASPACE(S) AND/OR HIPERSPACE(S) USED
WER417H 491,624K BYTES OF SHS AREAS CREATED, 424,410K BYTES USED
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER494I INPUT PHASE USED MIDAW
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
I am not a SYNCSORT expert, but it would be wise to
investigate with Your support why in the second run
the SYNCSORT GLOBAL DSM was not active and why SYNCSORT was not able to use DATA/HYPERspaces
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
How is the input for this sort built? Is there a smaller amount of data that is not in sequence that is being sorted together with a large amount of data that is already in sequence to create a complete file?
If so, suggest you consider sorting the small amount of data and then MERGing this with the larger, already sorted, file. The elapsed time improvement (as well as other resources required) will be greatly improved.
Thanks a lot for all your suggestions. I would look for the right schedule changes for my job checking with the Production Control team and also would look how to simplify the SORT better with the MERGE option.
--
Thanks,
Vidhya
"If you have knowledge, let others light their candles with it. "
.jpg)
