Joined: 06 Jun 2008 Posts: 8505 Location: Dubuque, Iowa, USA
Your post has quite a few errors and problems with it. From the DFSMSdfp Storage Administration Reference manual (emphasis added by me):
The maximum size (in KB or MB) of a new data set. For non-VSAM data sets, the value is &SIZE plus 15 extents. For VSAM data sets, the value is primary + (123 * secondary * volume count) if extent constraint removal is set to No. If extent constraint removal is set to Yes, the value is &SIZE plus 7257 extents. See Using read-only variables for more information about the values of &MAXSIZE and &SIZE for VSAM data sets. Also see Constraints when using read-only variables.
Type: Suffixed numeric
Max value: 2147483647 for KB, 2097151 for MB
So depending upon the specifics, your formula for calculating space could be DRASTICALLY wrong.
Your query really should be addressed to your site support group, as they know your site's ACS routines a whole lot better than anyone on this forum will.
&MAXSIZE is a fairly useless variable since Extended Format QSAM files were allowed because it still thinks they're limited to 15 extents per volume rather than 123. I don't know why IBM haven't updated this to match the values it passes for VSAM. Very annoying.
You do have some other options available though. For example the &DSNTYPE variable indicates if a file is Extended Format or not and combined with the &SECOND_QTY and &SPACE_TYPE variables you can start to make some more informed decisions on what to do with the files. For example you can potentially assign different Dataclases that might have the Space Override option set to YES.
I don't understand your example space parameter...seems a bit strange as you haven't specified TRK or CYL but have a 0? Can't see how that would work. Also you have UNIT count and VOLUME count, it only needs to be one or the other. And in fact you shouldn't need either if the assigned Dataclas has Space Constraint Relief enabled because extra volumes would be dynamically added based on the DYNVOL value.
I'd suggest you look at the way your datasets are allocated. Try and move away from specifying in TRK or CYL if you can and use the Dataclases to assign space. If you can't use Dataclas for space then use the AVGREC keyword to request space in terms of the number of expected records in the file.
This requests enough space for 10000 x 20000 byte records for both Primary and Secondary space.
Even better, if you have a Dataclas with space set at a similar value, and it has Space Constraint Relief and DYNVOL you can just code as follows assuming the Dataclas is assigned in the ACS routines:
ps: You don't need the DCB= parameter anymore, just code LRECL & RECFM as above, and ommitting BLKSIZE is the same as coding BLKSIZE=0. And with the dataset being SMS managed you don't need to specify UNIT count, that was only necessary for pre-SMS allocations using esoteric pools.
First of all I have to mention that this is not my coding and observed one of the application coded like this and as a storage admin I am trying to understand how their datasets falling under the small storage group instead of big pool so that I can reach out to the application group to standardize the code.
By the way this file is not extended format. I understand the info you are saying but I am trying to understand what had happened to those datasets to fall in to this small group.
Actually I started to question myself over this and told myself RTFM, (which you could have done!), and found this:http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ickug00%2Fbuld.htm
Noet what it says for the RECALL environment. Your dataset may have found its way to the wrong pool if it had been migrated and then recalled because the &SIZE and &MAXSIZE variables have no value in that environment. It depends what else you have in your ACS routines. Again try out the various options using the Testcase facility for both the ALLOCATE and RECALL environments.
Ensuring correct values for &SIZE and &MAXSIZE
If you allocate a data set using the TSO/E ALLOCATE command and you do not explicitly specify space requirements, then &SIZE and &MAXSIZE do not contain the correct values. Instead they both contain a value of zero. If your ACS routines rely on the values of &SIZE or &MAXSIZE in this situation, the data set might be assigned to the wrong class or group.
For a VSAM data set definition, the &SIZE and &MAXSIZE read-only variables reflect the space value specified in the CLUSTER component. If one is not specified in the CLUSTER component, then the space value specified in the DATA component is used. If a space value also is specified for the INDEX component and it is of the same type of space unit; for example, both are in tracks, cylinders, KB or MB, it is added to what was specified for the DATA component. If the INDEX component space unit is not of the same type as specified for the DATA component, it is ignored and not added to &SIZE or &MAXSIZE. For DFSORT work data sets, &SIZE and &MAXSIZE are zero. In the RECALL environment, &SIZE and &MAXSIZE are zero for empty partitioned data set and PS data sets because the size of the existing data set is not known at the time that DFSMS runs its ACS routines.
As input to data class ACS routine, &SIZE and &MAXSIZE are calculated from space information from JCL or IDCAMS, as follows:
•For non-VSAM data sets:
◦&SIZE = P + Directory (if any).
◦&MAXSIZE = P + (S*15) + Directory (if any).
•For VSAM data sets:
◦&SIZE = P.
◦&MAXSIZE = P + (S*254).
After data class is derived by the data class ACS routine, &SIZE and &MAXSIZE are recalculated depending on whether Extent Constraint Removal is specified or not in the selected data class before calling subsequent data class routines, as follows:
•For non-VSAM data sets, if no space is specified on JCL, then the space values defined in the selected data class are used to recalculate &SIZE and &MAXSIZE as follows:
◦&SIZE = P + Directory (if any).
◦&MAXSIZE = P + (S*15) + Directory (if any).
•For VSAM data sets, regardless whether space is specified or not, &MAXSIZE is recalculated depending on the specification of Extent Constraint Removal attribute as follows:
◦If Extent Constraint Removal = NO, then &MAXSIZE = P + (S*122)*volcnt.
◦If Extent Constraint Removal = YES, and the ADD' '1 Volume Amount in Data Class = P, then &MAXSIZE = ((P+S*122))*volcnt.
◦If Extent Constraint Removal = YES, and the ADD' '1 Volume Amount in Data Class = S, then &MAXSIZE = ((P+S*122)) + ((S*123)*(volcnt-1)).
yes Wilson , Exactly this is what I read and calculated the values and posted.
First thing this is a GDS so nonvsam , it doesn't have extent constraint removal ,no directory blocks hence the straight formula is as above mentioned ◦&SIZE = P , ◦&MAXSIZE = P + (S*15) .
I already did the test case and found the result going to bigger pool with same values that is why not able to understand how this logic is satisfied
as you mentioned the AND for MAXSIZE . No other logic satisfied in acs routine except this which I am very sure.
I tried to create a dataset with same coding in jcl and went to big pool , also it got Block size as 27998
I ran a test allocation as per your example DD (fixing syntax error ...you missed a right bracket on the SPACE parm)
The size of the file allocated was 4800trks which is around 256-259MB depending how you calculate it. This exceeds your &SIZE value and &MAXSIZE values (assuming 15 * 256MB = 3844MB)
We can't see where this WHEN statement is in relation to other WHEN's or SELECT groups and their relative END and EXIT statements. There may be something else that takes precedence to this code, or later code is taking effect if you haven't coded an EXIT after your OTHERWISE. Is PRDSML assigned anywhere else in the code for example? You may need to get a few WRITE statements in the appropriate parts of the code to work out when the assignments are being made.
I'd also be inclined to change your criteria to the following as it would make more sense I believe:
WHEN ((&SIZE LT 212MB AND &MAXSIZE LT 848MB) OR
(&DSORG EQ 'VS' ))