|
View previous topic :: View next topic
|
| Author |
Message |
Perry
New User
Joined: 01 Apr 2010
Posts: 2
Location: UK
|
|
|
|
Greetings
My site makes heavy use of temporary dataseta in JCL/Procs etc.
We have frequent S*37 problems on them, the data they hold has frequent, difficult to predict spikes.
I would like to be able to monitor actual space useage of temporary ( eg &&foobar ) datasets, in order to get an insight into those which are going multi-extent, and allow for recoding on JCL prior to an actual S*37 occuring.
Are there any SMF records that would help me ( type 15 maybe?) or can anyone recommend an approach? |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Type 15 may be of some use to you. I did do an analysis many years ago and might have the code somewhere. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
This was written for z/OS 1.4 but hopefully the SMF records have not changed too much, if any, since the good old days.
I assume that you have SAS available 
| Code: |
IF RECTYPE = 15 THEN DO;
INPUT @003 SMFTIME ?? SMFSTAMP.
@011 SYSTEMID $4.
@023 READER ?? SMFSTAMP.
@015 JOBNAME $8.
@042 NUMBUCB PIB1.
@053 DDNAME $8.
@065 DATASET $44.
@257 TRACKS3 PIB4.
@271 VOLSER $6.
@282 EXTENTS PIB1.
@285 EXCPCNT PIB4.
@289 TRACKS1 PIB4.;
IF DATASET = ' ' THEN DELETE;
TRACKUSD = TRACKS1 - TRACKS3;
RUNDATE = DATEPART(SMFTIME);
RUNTIME = TIMEPART(SMFTIME); |
|
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| With my little knowledge, suggest, run the TSO command PARMLIB; if you are allowed, no operands but you must be allowed to execute it. Look at the value for 'VIO' . That's where the temporary output goes. The default is supposed to represent VIO, meaning that a memory-resident 'file' holds the data before being written to spool (or may be to a named output dataset.) On most tof the shops, they direct VIO to real DASD because a truly gigantic PDS can overload auxiliary storage and cause space abends. You might be using an esoteric for 'VIO' that has only a few volumes associated with it. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
Anuj,
the VIO limit is usually set within the SMS subsystem, and is quite often quite a low threshold so that most && datasets do in fact get routed to DASD rather than VIO.
There could be a couple of things that may be causing the problem here, one being that the && datasets need to be adjusted to reflect the actual sizes being used, or that the storage group may just be over utilised at certain moments of the batch cycle.
Hopefully 'ye olde' SAS code from 1797 might still work  |
|
| Back to top |
|
|
Perry
New User
Joined: 01 Apr 2010
Posts: 2
Location: UK
|
|
|
|
Thanks folks:
looks good, I'm sure I can use the 15s for what I need.
BTW, A colleague mentioned CA-MICS as a possible tool, has anyone done anything of this nature with it? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Record type 15 is for OUTPUT, UPDAT, INOUT, or OUTIN,
maybe you need also type 14 : INPUT or RDBACK.
MICS is terrible in case of reruns, thats why i kept far away from it.
We used MICS to see if OPC deadlines were kept or not, but nowadays
there are better tools (maybe homemade) to do that.
My experience is that MXG is a much nicer tool to work with, but then
you need SAS. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
Thank you expat - hopefully Perry gets his way to go... |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 580
Location: London
|
|
|
|
| Some places turn off SMF for TEMP's to reduce the size of the MANx files, in which case JCL library scans may be needed. |
|
| Back to top |
|
|
|
|
