Page 1 of 2

Program execution statistics

PostPosted: Mon May 25, 2009 7:24 pm
by jeroc
Hello,

I would like to find programs of an application that impact performance and that should be improved.Is there some tool that allow to know how many times a program has been executed on the zOS and what is its average execution time?

My goal is to send this information onto Windows in order to process it. So the tool must provide to export information in a Windows readable text format.

Re: Program execution statistics

PostPosted: Mon May 25, 2009 10:11 pm
by dick scherrer
Hello,

All of the information about jobs that have executed is in the SMF records.

There are probably already jobs run daily, weekly, or monthly that organize this info by job and by program (most organizations have such processes running).

Suggest you talk with your system support people and find out what is available before you waste a lot of time and system resources re-creating something that already exists.

If you parse an existing report or write something more custom, it is a trivial matter to write the file as a delimited text file (the tab character x'05' works well) and ftp this file to some Windows server for local use.

Re: Program execution statistics

PostPosted: Tue May 26, 2009 3:48 pm
by jeroc
Hi Dick,

Thanks for your answer. I agree with you to avoid wasting time to recreate existing infos. Are SMF infos always available or people can deactivate their production?

Regards

Re: Program execution statistics

PostPosted: Tue May 26, 2009 11:36 pm
by dick scherrer
Hello,

Are SMF infos always available or people can deactivate their production?
Some amount of SMF data is always available. I've not seen anywhere that people could selectively deactivate "their" information. Not all systems capture all of the same information. Suggest you speak with the people who use the current SMF data and see what is available.

Re: Program execution statistics

PostPosted: Tue Jun 02, 2009 8:29 pm
by jeroc
Ok. So it is possible to have CPU time for online and batch programs. I am going to speak about his with system people.

Do you know other similar tools?

Regards

Re: Program execution statistics

PostPosted: Tue Jun 02, 2009 11:35 pm
by dick scherrer
Hello,

So it is possible to have CPU time for online and batch programs.
Yes.

Do you know other similar tools?
SMF captures data. . . It is common across all mvs-style installations. It is not a "tool" - things that report against the smf data are tools - and there are very many.

I am going to speak about his with system people

They can tell you what is already available on your system.

Re: Program execution statistics

PostPosted: Wed Jun 03, 2009 2:51 am
by Bill Dennis
dick scherrer wrote:I've not seen anywhere that people could selectively deactivate "their" information.
In PARMLIB member SMFPRMxx you can select the SMF record types to be written or not written.

Re: Program execution statistics

PostPosted: Wed Jun 03, 2009 3:11 am
by dick scherrer
Hi Bill,

Yup, but by record type.

User ax713r cannot do anything that would prevent smf records for userid=ax713r from being written can they?

Re: Program execution statistics

PostPosted: Mon Jun 08, 2009 2:06 pm
by jeroc
Hi both,

I am going to investigate on how to have SMF infos. It is interesting to know if some programs are time consuming. This may mean that there is probably something to do to improve their performance.
Potential causes could be in loops or in database accesses (bad WHERE clauses or missing indexes). What do think about that?

Re: Program execution statistics

PostPosted: Tue Jun 09, 2009 3:28 am
by dick scherrer
Hello,

The amount of time taken is not necessarily an indicator of poor performance. . .

Some tasks are simply big tasks. Some tasks become big due to very poor design - like passing a 300 million record file 5 times in utility steps rather than writing one programs that could accomplish the same real work.

Loops tend to identify themselves by having a time-out abend.

Poor database design and/or "bad" WHEREs often cause major performance problems. Especially when all of the pre-Production testing was done with insufficient data. Something that runs sub-second for 100 rows may grind completely to a halt with several million. . .