My personal philosophy is that computers are better than humans, in general, 
dealing with these kinds of things.

In any case, here are our DFSORT customizations in our ICEPRMxx member:


JCL                   
   DYNALOC=(SYSDA,12) 
   DYNAUTO=YES        
   MSGDDN=SYSOUT      
   PARMDDN=DFSPARM    
   SMF=NO             
INV                   
   DYNALOC=(SYSDA,12) 
   DYNAUTO=IGNWKDD    
   ERET=ABEND         
   MSGDDN=SORTMSG     
   PARMDDN=SORTPARM   
   SMF=SHORT          


Specifically, the ones of interest are DYNALOC and DYNAUTO.  This allows one to 
not specify any SORTWKxx DDs.  It dynamically allocates 12 of them.  We don't 
override DYNSPC, so it defaults to 256 (megabytes).


JCL is used for JCL invoked sorts; INV for program invoked sorts.


If it were totally up to me I would have made the JCL options exactly the same 
as the INV options.

We also have the following SMS data classes:
DATACLAS         AVG    SPACE    SPACE      VOLUME  ADDITIONAL  DYNVOL
NAME     AVGREC  VALUE  PRIMARY  SECONDARY  COUNT   VOLUME AMT  COUNT 
--(2)--- -(8)--  -(9)-  -(10)--  --(11)---  -(14)-  ---(15)---  -(16)-
JUMBO    M       -----     3000       1500     ---  ---------        9
LARGE    M       -----     1000        500     ---  ---------        9
MEDIUM   M       -----      100         50     ---  ---------        9
SMALL    M       -----       10          5     ---  ---------        9
TINY     K       -----     1024        512     ---  ---------        9
MINI     K       -----       20         20     ---  ---------        9
NULL     -       -----        0          0       1  ---------       --

(Notes: TINY and MINI probably should be reversed, but we had already defined 
and started using TINY before we decided to have an even smaller one.  Also 
note that even though mini is defined as 20/20 it will always allocate the 
minimum of 1 track.)

It's not perfect, as nothing is, but seems to work satisfactorily.

Frank



>________________________________
> From: John McKown <[email protected]>
>To: [email protected] 
>Sent: Sunday, September 9, 2012 7:40 PM
>Subject: Disk data set space allocation, philosophy
> 
>I decided to ask this forum about a "problem" we have were I work. In
>summary, the programmers don't want to be forced to specify SPACE
>parameters in the JCL (or IDCAMS DEFINEs). They also don't want to be
>forced to use SORTWKnn allocations or do specify any SIZE type
>parameters in the controls. This latter works for JCL invoked DFSORTs. I
>have set the default so high that it can sort almost anything in the
>shop. I say "almost" because we had a job abend SE37-08 in an internal
>sort. My solution was to tell the person responsible for the job to
>change it to include about 30 SORTWKnn DD statements with
>SPACE=(CYL,(2000,100)). The only reason that I said so "over the top"
>was to be 99.9% sure that would be enough. But I will bet that the
>programmer will complain.
>
>They, basically, just want the system to handle space allocations. We do
>not have, and WILL NOT ACQUIRE any software such as SRS. We only use
>what is available with DFSMS and DFSORT. The previous storage
>administrator set up every DISK DATACLAS with a Dynamic Volume Count of
>59, which is the max, and told the programmers to use
>SPACE=(CYL,(500,100)) for everything, unless they thought that they
>needed more. The tape DATACLAS is set up to make the default 190 tapes,
>instead of the "normal" 5, because "it would take too much work to make
>JCL changes". This latter I can understand because 90% of the work is
>putting in Change Control paperwork (no, this will not change). 
>
>I have tried everything that I can think of to basically tell SMS to
>allow "unlimited" allocations. Have I missed some SMS parameter? Should
>I make all sequential data sets "extended format" so that they can have
>123 extents per volume instead of only 16? Is there any negative to
>this? More CPU, slower I/O, anything? Does it work with DFSORT SORTWKnn
>DDs, the DFSORT manual seems to say that it does.
>
>If you noticed from previous messages, IT management is anti-z/OS so
>they basically just don't work to be bothered with it. Like because
>MS-Windows is such a POS that they need to concentrate on it. Makes me
>wonder why they adore it.
>
>-- 
>John McKown
>Maranatha! <><
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
>
>
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to