| Date: | Fri, 25 Apr 1997 13:46:51 -0400 |
| Reply-To: | "Rickards, Clinton S" <RickardsCS@AETNA.COM> |
| Sender: | "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU> |
| From: | "Rickards, Clinton S" <RickardsCS@AETNA.COM> |
| Subject: | FW: Capture Performance Stats in Jobstream? |
|
I don't have a specific solution for you but I do a thought. Since you
are running in MVS, why not send the SASLOG (with appropriate stats
included) to a physical file and then process the SASLOG in a subsequent
SAS step in the same job. Something like this:
//ASDFG JOB ...
//SASSTEP EXEC SAS ...
//SASLOG DD DSN=...
//SYSIN DD *
your sas code here...
//STATS EXEC SAS
//INLOG DD DSN=*.SASSTEP.SASLOG,...
//SASLOG DD SYSOUT=*
//SYSIN DD DSN=SOURCELIB(DOSTATS),
Depending on your needs, you could consider adding the STATS step to
your SAS procedure. The trick is going to be finding the stats in the
SASLOG...
Clint
Clint Rickards, ARS IT, TNB2
Phone: 860-273-3420
>----------
>From: SLYN19A@prodigy.com[SMTP:SLYN19A@prodigy.com]
>Sent: Fri, Apr 25, 1997 9:10 am
>To: SAS-L@VTVM1.CC.VT.EDU
>Subject: Capture Performance Stats in Jobstream?
>
>We would like to capture some basic performance stats in a very
>"controlled" SAS jobstream under MVS. That is, the code is generated
>from some "set up" screens, so we can insert code or macros anywhere in
>the SAS
>program or in the JCL. We are basically only interested in the CPU and
>I/O usage, and perhaps some measure of memory usage.
>
>The CPU and I/O stats are to be paired with Data warehouse indicators (on
>
>table and column usage) and used to analyze ways to improve the
>data warehouse structure. We would prefer to do this pairing at run time
>so
>that all of the information can be logged to a distinct tracking data set.
>
>
>I am aware of the stimer, memrpt, stats, and fullstats parameters to send
>info
>to the log, and the SMF parm to send records to SMF. But, again, we
>would much rather capture the data at run time (with a call to something
>or a macro
>invocation) and log it to a distinct data set with the other data
>warehouse info that is being captured.) We would like to stay away from
>pulling usage (performance) info from SMF and merging with the other job
>related data that is being logged to a special data set.
>
>Ideas? Secrets? Existing exits?
>
>Rick Nicola
>SPS Software Services Inc.
>SAS Quality Partner
>
|